Skip to main content
Glama
BigfootBytes

threatlocker-mcp-server

by BigfootBytes

ThreatLocker Scheduled Actions

scheduled_actions

List and manage scheduled ThreatLocker agent version updates. Filter by organization or computer group, get details, schedule batched rollouts, or abort pending actions.

Instructions

Query ThreatLocker scheduled agent actions.

Scheduled actions are pending operations on ThreatLocker agents, primarily version updates. Updates are batched and scheduled within maintenance windows to avoid disruption.

Common workflows:

  • List all scheduled actions: action=list

  • Search with filters: action=search, organizationIds=["..."], computerGroupIds=["..."]

  • Get scheduled action details: action=get, scheduledActionId="..."

  • Get available targets for scheduling: action=get_applies_to

Scheduled action types: Version Update (scheduledType=1).

Pitfalls:

  • isAscending is inverted by the API: true (or omitted) sorts descending (high to low); set false for ascending.

  • search (GetByParameters) is keyed by scheduledId — pass it to filter to a specific scheduled action's computers; use list for the top-level set.

Permissions: Edit Computers, Edit Computer Groups, View Computers. Pagination: search action is paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: scheduledAgentActionId, scheduledType, scheduledDateTime, computerName, computerGroupName, status.

Related tools: computers (see current versions), computer_groups (target groups for updates), organizations (filter by org)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYeslist=all scheduled actions, search=filtered search, get=single action details, get_applies_to=available scheduling targets, schedule=schedule a batched agent version update, abort=cancel a scheduled action (abortAll=true for the whole action, or appliesTo=[computers] for specific ones)
osTypeNoFilter get_applies_to targets by OS: 1=Windows, 2=Mac, 3=Linux, 7=Red Hat Enterprise Linux 6
orderByNoField to sort by
abortAllNoabort: cancel the entire scheduled action across all targets. When true, appliesTo is ignored; when false/omitted, supply appliesTo.
pageSizeNoResults per page (default: 25, max: 500)
appliesToNoTargets for schedule (each {appliesToId, appliesToTypeId}); for abort, the computers to cancel (each {appliesToId}). Resolve ids via get_applies_to.
startDateNoWhen the rollout starts (ISO 8601). Defaults to now.
pageNumberNoPage number (default: 1)
searchTextNoFree-text filter for search (e.g. computer name).
batchAmountNoComputers updated per batch (REQUIRED for schedule). Omitting it would update the whole fleet at once.
isAscendingNoSort order. Note: the API inverts this — true (or omitted) returns results in descending order (high to low); set false for ascending. Default: true.
scheduledIdNoFilter search to the computers within a specific scheduled action (GUID). Find via list first.
fetchAllPagesNoFetch all pages automatically (max 10 pages). Default: false (single page).
scheduledTypeNoScheduled type: 1=Version Update (the only supported type). Default: 1.
windowEndTimeNoDaily window end, 24h "HH:MM".
includeChildrenNoInclude child organizations (list and get_applies_to actions)
organizationIdsNoFilter by organization GUIDs. Find via organizations first.
response_formatNoOutput format: markdown (default, human-readable) or json (structured)markdown
targetVersionIdNoThreatLocker version GUID to roll out (schedule action). Get it from the versions tool value field.
windowStartTimeNoDaily window start, 24h "HH:MM".
computerGroupIdsNoFilter by computer group GUIDs. Find via computer_groups first.
scheduledActionIdNoScheduled action GUID (required for get). Find via list or search first.

Output Schema

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

TDQS

A4.4/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond annotations: the isAscending inversion pitfall, search being keyed by scheduledId, pagination behavior, required permissions, and key response fields. It also discloses that schedule/abort are mutations, which aligns with readOnlyHint=false.

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?

Despite being long, the description is well-structured with sections for workflows, pitfalls, permissions, pagination, response fields, and related tools. Every section earns its place given the tool's 22-parameter complexity and mixed read/write actions.

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?

The description covers typical workflows, important pitalls, permissions, pagination behavior, response fields, and relations to sibling tools. With an output schema present, no critical guidance is missing for an agent to select and invoke this tool correctly.

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?

With 100% schema coverage, baseline is 3, and the description adds meaning by explaining cross-parameter behavior: how scheduledId filters search, how batchAmount omission affects scheduling, how isAscending is inverted, and how fetchAllPages works. This exceeds what the schema alone provides.

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

Purpose4/5

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

The description clearly names the resource (ThreatLocker scheduled agent actions) and lists the main query workflows, distinguishing it from related tools. However, the opening verb 'Query' understates the tool's full scope, since the action enum also includes schedule and abort mutations.

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?

Common workflows map actions to use cases, and related tools are named with their purpose (computers, computer_groups, organizations). It gives good context but does not explicitly state when not to use this tool versus a specific alternative.

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