threatlocker-mcp

approval_request_permit_application

Approve a permit application request by selecting matching applications, setting policies, and defining scope for ThreatLocker portal.

Instructions

Approve Permit Application Request WORKFLOW: take_ownership -> get_permit_application_by_id -> application_get_matching_list -> permit_application. Start from the DTO returned by get_permit_application_by_id and modify the choices below. REQUIRED FIELDS (KB-documented, all must be present): approvalRequest.approvalRequestId; approvalRequest.json -- copy verbatim from get_permit_application_by_id (server uses it to reconstruct file/action context, omitting it causes silent failures); userinstance -- the portal shard ('h', 'g', etc.), parsed from the request's portalApiUrl subdomain; isFromApproval: true; hasOriginApprovalCenter: true; actionType (copy from request: 'elevate'/'execute'/'install'); osType (1=Windows, 2=Mac, 3=Linux, 5=WinXP); organizationId, computerId (copy from request); organizationIds -- list of parent org IDs above the request's org ([] for top-level); fileDetails.fullPath. APP SELECTION (set exactly ONE mode on matchingApplications): (a) PREFERRED -- use application_get_matching_list result. Prefer tenant-owned match (its organizationId equals the call's organizationId) over master-org/BUILT-IN (organizationName: "master"). Set useMatchingApplication: true, populate matchingApplication with the chosen result; set others false and their objects to null. The DTO's hasMatchingApplication flag is UNRELIABLE -- trust application_get_matching_list.hasMatching instead. *** CRITICAL -- BUILT-IN match REQUIRES entire-org scope. When the chosen match has organizationName: "master", you MUST set policyLevel.toEntireOrganization: true. Pairing a BUILT-IN with computer-scope returns HTTP 401 "Missing the '' permission" (misleading -- it's actually a body-shape error). Verified 2026-05-21. Tenant-owned matches and new apps use the default all-flags-false scope. (b) FALLBACK -- add to existing custom app (discover via application_get_for_application_options). Set useExistingApplication: true, populate existingApplication; others null. (c) LAST RESORT -- create new app. Set useNewApplication: true and newApplicationName to a non-null derived name (e.g. file stem title-cased: vlc.exe -> "VLC"). Null returns HTTP 417 'Must enter a name for a new application'. POLICY (policyConditions.ruleId): 0=manual rules, 1=Install Mode 1hr, 2=Learning Mode 1hr, 3=Monitor Mode 1hr. Set useExistingPolicy: true to reuse an existing policy (manualOptions then carries the rule criteria). SCOPE (policyLevel): default 'this computer' = ALL THREE flags false (toEntireOrganization/toComputerGroup/toComputer); scope is inferred from top-level computerId. Setting toComputer: true returns HTTP 417 'Provided applies to ID does not associate with a known OS type'. For computer group, set toComputerGroup: true and populate selectedComputerGroup (discover via computer_group_get_dropdown_by_organization_id). For entire-org, set toEntireOrganization: true. ACTION TYPE: for elevate set isElevationRequest: true and isExecutionRequest: false; for execute reverse. Both are spec-readOnly but MUST be sent matching the action. SHAPE: send null (not omit) for unused sub-objects -- matchingApplication, existingApplication, selectedComputerGroup, policyExpirationDate, elevationExpirationDate. Wrong shape = opaque HTTP 500. PERMISSIONS: API key user needs one of 'Approve for Entire Organization', 'Approve for Group', 'Approve for Single Computer', or 'Approve for Single Computer Application Only' in Administrators.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "body": "<body>"
    },
    "name": "approval_request_permit_application"
  }
}

Input Schema

Name	Required	Description
`body`	Yes	Request body.
`organization_id`	No	Override the default organization (ManagedOrganizationId header).
`override_organization_id`	No	Optional OverrideManagedOrganizationId header.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Jun 14, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description fully carries the burden. It discloses critical behaviors: the unreliable hasMatchingApplication flag, silent failures when omitting json, error mappings for wrong shape (HTTP 500), permission requirements, and the verified date for BUILT-IN scope requirement. This is exceptionally transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-organized with clear sections (workflow, required fields, app selection, policy, scope, shape, permissions). Every sentence provides actionable guidance. While verbose, the density is justified by the tool's complexity; minimal fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex nested schema and no output schema, the description covers all necessary aspects: workflow prerequisites, field-level requirements, selection logic, error scenarios, permissions, and shape rules. It is self-contained and leaves no major gaps for a competent agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for top-level params but the nested body object lacks descriptions. The description compensates fully by explaining required fields, exact values (e.g., osType mapping, actionType options), copy instructions, and complex logic for matchingApplications, policyConditions, policyLevel. It adds immense meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Approve Permit Application Request' and specifies the workflow chain (take_ownership -> get_permit_application_by_id -> ...). It clearly distinguishes from sibling tools like approval_request_get_by_id or approval_request_update_for_reject by focusing on the approval action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides detailed usage guidance: the required workflow, three app selection modes with clear priority, policy and scope rules, and error conditions (401, 417, 500). It does not explicitly compare with all siblings but strongly implies when this tool is appropriate (after fetching the permit application).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server