Skip to main content
Glama
BigfootBytes

threatlocker-mcp-server

by BigfootBytes

ThreatLocker Approval Requests

approval_requests
Destructive

Query and manage ThreatLocker approval requests created when users request access to blocked software. List, review, approve, reject, or ignore pending requests and generate policies.

Instructions

Query ThreatLocker approval requests.

When users encounter blocked software and request access, it creates an approval request. Admins review these requests to decide whether to permit the software by creating policies.

Common workflows:

  • List pending requests: action=list, statusId=1

  • Get pending request count: action=count

  • Find requests for a specific user: action=list, searchText="username"

  • Get request details: action=get, approvalRequestId="..."

  • Get file info for download/analysis: action=get_file_download_details, approvalRequestId="..."

  • Get permit options (apps, groups): action=get_permit_application, approvalRequestId="..."

  • Get storage request details: action=get_storage_approval, approvalRequestId="..."

  • Approve a request: action=permit. Two-step — call get_permit_application first, round-trip its opaque "json" blob into permitJson, then pick permitMode + policyLevel. Payload-verified, NOT live-tested: validate in a non-prod org before relying on it.

Request statuses: 1=Pending (needs review), 4=Approved, 6=Not Learned (learning mode), 10=Ignored, 12=Added to Application, 13=Escalated (from Cyber Heroes), 16=Self-Approved

Pitfalls:

  • list defaults to newest-first (isAscending=false) — the right default for triaging the pending queue.

  • Permitting a request is a two-step flow: call get_permit_application first and round-trip its opaque "json" blob; don't synthesize it.

  • Before approving a Built-In matching app, confirm the file isn't a shared DLL matching unrelated apps (you'd permit the whole built-in).

Permissions: View Approvals, Approve for Entire Organization/Group/Single Computer. Pagination: list action is paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: approvalRequestId, username, fullPath, actionType, statusId, computerName, requestDateTime.

Related tools: action_log (see the deny event), applications (find matching apps), policies (create permits)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYeslist=search requests, get=single request details, count=pending count, get_file_download_details=file download info, get_permit_application=permit options, get_storage_approval=storage request details, reject=reject a pending request with a reason, take_ownership=assign a request to yourself, permit=approve an application request (round-trip the opaque json blob), ignore=ignore a request, permit_storage=approve a storage/USB request (round-trip get_storage_approval json), get_testing_environment=file/testing-env details for a request
osTypeNopermit: 1=Windows, 2=macOS, 3=Linux, 5=Windows XP.
ruleIdNopermit: 0=manual rules, 1=Installation Mode 1hr, 2=Learning Mode 1hr, 3=Monitor Mode 1hr.
orderByNoField to order by (default: datetime)
commentsNopermit: comment on the request. NOTE: overwrites any existing comment if provided.
fullPathNopermit: file path of the requested file (use \\ for backslashes).
pageSizeNoResults per page (default: 25, max: 500)
statusIdNoFilter by status: 1=Pending (default for list), 4=Approved, 6=Not Learned, 10=Ignored, 12=Added to Application, 13=Escalated, 16=Self-Approved
ticketIdNopermit: ticket id. NOTE: overwrites existing value if provided.
computerIdNopermit: requesting computer GUID.
entityTypeNopermit_storage: scope level for a new policy (0=computer, 1=group, 2=org).
pageNumberNoPage number (default: 1)
permitJsonNopermit: the opaque "json" blob from get_permit_application, passed back VERBATIM. Do not synthesize or edit it.
permitModeNopermit: existing_app=add file rule to an existing application; matching_app=use a ThreatLocker-matched application; new_app=create a new application. Requires applicationId+applicationName (existing/matching) or newApplicationName (new).
policyNameNopermit_storage: name for the new storage policy (required for storageMode=new_policy).
searchTextNoFilter by text
appliesToIdNopermit_storage: entity GUID the new policy applies to.
isAscendingNoSort ascending. Default: false (newest-first), the right default for triaging the pending queue.
policyLevelNopermit: scope the resulting policy to the entire organization, the computer group, or just the requesting computer.
storageJsonNopermit_storage: the opaque "json" blob from get_storage_approval, passed back VERBATIM.
storageModeNopermit_storage: add_to_existing=attach the device to an existing storage policy (needs storagePolicyId); new_policy=create a new storage policy (needs policyName).
allFilePathsNopermit_storage: permit all file paths on the device (default: false); otherwise set selectedPath.
ignoreReasonNoReason shown to the requestor when ignoring (ignore action).
rejectReasonNoReason shown to the requestor when rejecting (reject action).
selectedPathNopermit_storage: specific path to permit when allFilePaths=false.
applicationIdNopermit: application GUID (required for permitMode existing_app/matching_app).
fetchAllPagesNoFetch all pages automatically (max 10 pages). Default: false (single page).
ignoreSubjectNoOptional response email subject for ignore.
manualOptionsNopermit: file-rule conditions. A hash rule = { "hash": "..." } and NOTHING else. A property rule = any of { fullPath, cert, processPath, createdBy } (pair at least two for a stronger rule).
sourceTableIdNoget_testing_environment: source log table (1=ActionLog, 2=DenyActionLog, 3=Baseline, 4=EventLog; default 2).
expirationDateNopermit_storage: approval expiry in UTC (YYYY-MM-DDTHH:MM:SSZ).
notifyOnIgnoreNoEmail the requestor on ignore (default: false).
organizationIdNopermit: organization GUID of the request.
responseReasonNoOptional response email body for reject.
applicationNameNopermit: application name (required for permitMode existing_app/matching_app).
computerGroupIdNopermit: computer group GUID (used as selectedComputerGroup when policyLevel=computer_group).
elevationStatusNopermit: 0=do not elevate, 1=elevate, 2=silent elevation (only with the Elevation product).
organizationIdsNopermit: parent-hierarchy GUID chain (child→…→root); usually 1 entry for a child-org request.
responseSubjectNoOptional response email subject for reject.
response_formatNoOutput format: markdown (default, human-readable) or json (structured)markdown
storagePolicyIdNopermit_storage: existing storage policy GUID (required for storageMode=add_to_existing).
notifyOnResponseNoEmail the requestor on response (reject/permit_storage; default: false).
allStorageDevicesNopermit_storage: apply to all storage devices (default: false).
approvalRequestIdNoApproval request GUID (required for get, get_file_download_details, get_permit_application, get_storage_approval). Find via list action first.
networkExclusionsNopermit: network exclusions applied to the resulting ringfence permit.
ringfenceActionIdNopermit: ringfence action id applied to the permit.
useExistingPolicyNopermit: update an existing policy affecting the computer instead of creating one (default false).
newApplicationNameNopermit: name for the new application (required for permitMode new_app).
elevationExpirationNopermit: elevation expiry in hours (used when elevationStatus>0).
showCurrentTierOnlyNoOnly show requests at the current approval tier (multi-tier/MSP escalation; default: false)
policyExpirationDateNopermit: expiry for the created policy in UTC (YYYY-MM-DDTHH:MM:SSZ).
requestorEmailAddressNopermit: requestor email. NOTE: overwrites existing value if provided.
ticketApprovalManagerNopermit: approval manager. NOTE: overwrites existing value if provided.
showChildOrganizationsNoInclude child organizations (default: false)
applicationOrganizationIdNopermit: organization GUID that owns the application (defaults to organizationId).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoResponse data — shape varies by action
errorNo
successYes
paginationNo
Install Server

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark destructive=true, readOnly=false, idempotent=false, openWorld=true; the description goes beyond by detailing the two-step permit flow, warning not to synthesize the opaque json blob, cautioning about Built-In matching apps matching unrelated shared DLLs, listing required permissions, and explicitly admitting 'Payload-verified, NOT live-tested: validate in a non-prod org before relying on it.' This is model transparency for a mutating tool.

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 appropriately so for a 55-param, 12-action tool. It is well-structured: summary, common workflows, statuses, pitfalls, permissions, pagination, key fields, related tools. It is front-loaded with the most useful workflows. Small deduction for some redundancy with schema descriptions (e.g., the opaque-json warning appears both in the schema and the description) and a few repetitive status/param notes.

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?

For a highly complex tool with 55 parameters, 12 actions, and no simple output contract explained, the description covers prerequisites (two-step flows), safety caveats, permission requirements, pagination behavior, response fields, status codes, and sibling relationships. It also mentions the open-world caveat via 'validate in a non-prod org.' Nothing essential for an agent to call the tool confidently seems missing.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3. The description does add meaning beyond the schema by grouping relevant parameters into workflows (permit flow, storage flow, list/count/get flow) and clarifying which action requires which preliminary call (get_permit_application before permit; get_storage_approval before permit_storage). It also adds high-level parameter semantics like 'fetchAlPages=true' for pagination and 'isAscending=false' as the right triage default. Minor deduction because much param-level detail is already in 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 opens with a clear verb and resource ('Query ThreatLocker approval requests') and quickly enumerates the domain: blocked-software requests created by users and reviewed by admins. It then provides concrete common workflows that distinguish the core actions (list, count, get, get_permit_application, permit) from one another, and names related siblings (action_log, applications, policies) to situate the tool. This is far beyond a vague one-liner.

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

Usage Guidelines5/5

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

It gives explicit when-to-use context for each common workflow, including specific parameter molds (action=list, statusId=1 for pending; searchText for user; two-step permit flow). It also gives alternatives: action_log for deny events, applications for matching apps, policies for creating permits, and even flags where the action is NOT live-tested. An agent can correctly select this tool and the right action without guessing.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BigfootBytes/threatlocker-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server