Skip to main content
Glama
BigfootBytes

threatlocker-mcp-server

by BigfootBytes

ThreatLocker Action Log

action_log
Read-onlyIdempotent

Query ThreatLocker unified audit logs to investigate endpoint events such as denies, network blocks, and PowerShell executions. Filter by date, hostname, or action type to pinpoint root causes.

Instructions

Query ThreatLocker unified audit logs.

The action log records all application control events: permits, denies, network access, file operations, PowerShell execution, elevation requests, and more. This is your primary tool for investigating what happened on endpoints.

Common workflows:

  • Find all denies in last 24 hours: action=search, startDate="...", endDate="...", actionId=99

  • Find denies on a specific computer: action=search, ..., hostname="COMPUTER-NAME"

  • Find network blocks: action=search, ..., actionType=network, actionId=2

  • Find PowerShell executions: action=search, ..., actionType=powershell

  • Get details of a specific event: action=get, actionLogId="..."

  • Track a file's history across all computers: action=file_history, fullPath="C:\path\to\file.exe"

  • Aggregate by user to find who's triggering denies: action=search, ..., groupBys=[1]

  • Get file download details: action=get_file_download, actionLogId="..."

  • Get policy conditions for permit: action=get_policy_conditions, actionLogId="..."

  • Get testing environment details: action=get_testing_details, actionLogId="..."

Pitfalls:

  • onlyTrueDenies/simulateDeny only filter when used alone or together; they force actionId=99 internally. "True" deny = enforced block; "simulated" = would-have-blocked on a Monitor/Learning computer.

  • When calling get/get_file_download, pass the sourceTableId matching the row the eActionLogId came from (default 2=DenyActionLog will miss permit/baseline/eventlog events).

  • groupBys takes at most 2 fields; prefer it over fetching raw rows for aggregation.

  • username/deviceType are NOT supported search filters here (the V2 endpoint ignores them); pivot on hostname/fullPath/policyId or use groupBys=[1] to break down by user.

Permissions: View Unified Audit. Pagination: search action is paginated (use fetchAllPages=true to auto-fetch all pages). Performance: always use date filters — queries without startDate/endDate can be very slow on large organizations. Use groupBys to aggregate instead of fetching all raw rows. Key response fields: actionLogId, fullPath, processPath, hostname, username, actionType, policyName, applicationName.

Related tools: computers (find computer IDs), applications (identify apps), approval_requests (handle denied software)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYessearch=query logs with filters, get=single event details, file_history=all events for a file path, get_file_download=file download info, get_policy_conditions=policy conditions for permit, get_testing_details=testing environment details, build_search_string=produce the opaque saveParameters string for saved_searches.insert (same filters as search)
endDateNoEnd date for search (ISO 8601 UTC)
actionIdNoFilter by action: 1=Permit, 2=Deny, 3=Deny (Option to Request), 6=Ringfenced, 99=Any Deny
fullPathNoFile path for search filter or file_history (wildcards supported)
groupBysNoAggregate results by up to 2 fields. Common: 1=Username, 2=Process Path, 5=Policy Id, 6=Policy Name, 7=App Id, 8=App Name, 9=Action Type, 11=Hash, 17=Asset Name, 65=Computer Id, 70=Risk Score, 71=Risk State. See threatlocker://enums and the unified-audit KB for the full ~55-code list.
hostnameNoFilter by hostname for search or file_history (wildcards supported)
pageSizeNoResults per page (default: 25, max: 500)
policyIdNoFilter search by the GUID of the policy that handled the event. Find via policies first.
startDateNoStart date for search (ISO 8601 UTC)
actionTypeNoFilter by a single action type
computerIdNoComputer GUID to scope file_history. Find via computers list first.
pageNumberNoPage number (default: 1)
actionLogIdNoAction log GUID (required for get, get_file_download, get_policy_conditions, get_testing_details). Find via search action first.
actionTypesNoFilter by multiple action types in one query
simulateDenyNoInclude what-if denies from Monitor Only mode computers (default: false)
fetchAllPagesNoFetch all pages automatically (max 10 pages). Default: false (single page).
getAllParentsNoOn get: include the full parent-process chain for the event (default: false)
sourceTableIdNoSource table for get/get_file_download: 1=ActionLog, 2=DenyActionLog (default), 3=BaselineActionLog, 4=EventLogActionLog. Must match the source table of the row the eActionLogId came from.
onlyTrueDeniesNoShow only real enforced blocks, excluding simulated denies from Monitor Only mode (default: false)
response_formatNoOutput format: markdown (default, human-readable) or json (structured)markdown
showKnownThreatsOnlyNoRestrict search to events flagged as known threats (default: false)
showChildOrganizationsNoInclude child organization logs (default: false)

Output Schema

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

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark the tool read-only and idempotent, and the description adds auth requirements, pagination behavior, performance caveats, and hidden couplings like onlyTrueDenies/simulateDeny forcing actionId=99 and sourceTableId default 2 missing other event tables. Nothing here contradicts the annotations.

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

Conciseness5/5

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

The description is long but front-loaded and sectioned into workflows, pitfalls, permissions, pagination, performance, key fields, and related tools. For a tool with 7 action modes and 22 parameters, every section earns its place.

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?

It covers all action modes, common workflows, failure modes, authorization, pagination, performance, and key response fields. With an output schema also present, nothing an agent needs to call this tool correctly is missing.

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%, but the description still enriches the schema with example query combinations, groupBys field codes, and cross-parameter constraints such as onlyTrueDenies forcing actionId=99. That is precisely the extra semantics needed for a 22-parameter tool.

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 unified audit logs.' It then lists what the log contains and calls itself the 'primary tool for investigating what happened on endpoints', which distinguishes it from sibling tools like computers or applications.

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 provides explicit common workflows for each action mode, negative filter guidance (username/deviceType are not supported, groupBys max 2), and a related-tools list for adjacent tasks. This lets the agent decide between action_log and its siblings.

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