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.

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.

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.

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.

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.

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.

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

Beyond the annotations, the description discloses critical behavioral details: create is metadata-only, delete vs delete_confirm removes without or with policies, hash-only rules must avoid path/cert, built-in applications take precedence, pagination behavior, and permission requirements. No contradictions with annotations were found.

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

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

The description is long, but it is front-loaded with the core purpose and organized into Common workflows, Pitfalls, Permissions, Pagination, and Key response fields. Every section earns its place given the tool's 14 actions and 34 parameters, and the formatting makes the information quickly scannable.

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

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

For a complex CRUD-plus-research tool, the description covers workflows, pitfalls, required permissions, pagination, response fields, and related tools. It also lists key response fields and research fields, so an agent can interpret results without needing the output schema. Nothing essential for correct invocation is missing.

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

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

Although schema coverage is 100%, the description adds substantial value by showing realistic action-parameter pairings, required prerequisites for parameters like applicationFileIds, and meaningful examples for search, match, create, update, add_file, and managedOrganizationId. This goes well beyond the schema's standalone explanations.

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

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

The opening sentence names the specific verbs (search, inspect, create, update, delete) and resource (ThreatLocker applications), then defines what an application is. The extensive workflow list makes each action's purpose concrete and distinguishes this tool from the sibling tools.

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

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

The description provides explicit common workflows for nearly every action, including parameter combinations like action=search, searchBy=hash. It also gives clear fallback and sequencing guidance, such as 'create makes metadata only — add file rules in a follow-up add_file call' and 'remove_file needs applicationFileId values from action=files first.' Related tools are named with their purpose, helping an agent choose this tool versus alternatives.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the global group's special 'permits applications across all groups' behavior, the policy-scope implication, required permissions, and key response fields. No contradictions with annotations.

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

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

The description is well-structured and front-loaded: purpose, domain concept, common workflows, permissions, key fields, and related tools. Every section earns its place; the workflow bullet list is dense but scannable. No filler or redundancy.

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

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

Despite 18 parameters and 5 action variants plus an output schema, the description covers all critical decision points: common workflows, permissions, key response fields, and relationships to sibling tools. The output schema itself handles return-value details, so nothing essential is missing for selecting and invoking the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning to several parameters by framing them in workflows (e.g., includeGlobal=true permits applications across all groups, osType enum examples, includeAllComputers for full group details). It also clarifies the 'global' concept and lists key response fields, enhancing the agent's understanding beyond the schema.

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

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

Opens with a specific verb and resource ('List and inspect ThreatLocker computer groups') and immediately clarifies the domain concept (groups organize computers and define policy scope). It also differentiates itself from sibling tools via the 'Related tools' line, explicitly stating computers lists computers in groups and policies are applied to groups.

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

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

The 'Common workflows' section gives explicit action+parameter recipes for common scenarios: list with includeAllComputers, dropdown for UI selection, dropdown_with_org for MSP, osType filters, get_for_permit for approval workflow, and get_by_install_key with a 24-char key. It also lists required permissions. However, it does not explicitly state when NOT to use this tool versus alternatives, only a brief related-tools pointer.

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

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

Annotations already flag destructive/non-readOnly behavior, and the description reinforcees and expands this with critical nuances: delete removes from Portal but does NOT uninstall, get returns editable record not live protection state, restart_org can hit child orgs, and remove_dupicate is for duplicate records. No contradiction with annotations; the description adds material safety-relevant behavior.

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

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

Well-organized into labeled sections: Common workflows, Pitfalls, Permissions, Pagination, Key response fields, Related tools. Front-loaded with the primary purpose, then bullet lists that are easy to scan. It is long, but appropriate for a 34-parameter multi-action tool where every section adds load-bearing information.

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

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

Given the large parameter count, output schema, and annotations, the description covers the essential operational context: how to find computers, what each major action does, permissions needed, pagination behavior, key response fields, and related tools. No critical gap that would leave an agent guessing how to invoke the tool for common workflows.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds real value by combining parameters into workflows (e.g. deleteComputers all in same org, fetchAllPages for paginated list/checkins, move_org requires osType + target ids). It doesn't fully enumerate every action's required parameter set, but the workflows and pitfalls cover the most important combinations.

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

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

Opens with a clear verb + resource ('Query and inspect ThreatLocker computers') and the workflow list gives concrete action+parameter combinations for each major operation. The Related tools section explicitly names computer_groups, maintenance_mode, and action_log, distinguishing this tool from its siblings. Although the opening phrase 'Query and inspect' slightly undersells the mutating/delete actions, the workflow list quickly disambiguates.

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

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

Provides explicit when-to-use guidance with exact action+parameter recipes, e.g. 'Find computers by logged-in user: action=list, searchBy=2, searchText="username"'. Pitfalls direct agents away from get for live state and toward list or maintenance_mode history. It also positions the tool as the triage entry point and recommends hand-off to maintenance_mode, approval_requests, or action_log.

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

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

Even with readOnlyHint=false and destructiveHint=true annotations, the description adds substantial behavioral context: what each maintenance mode type does, silent failure of Learning Mode without a Default Deny policy, version requirements for Isolation/Lockdown, usersList format, default 1-hour window, required permissions, pagination behavior, and key response fields. This goes well beyond the annotations and is consistent with them.

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

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

The description is long but well organized into labeled sections: types, workflows, pitfalls, permissions, pagination, response fields, and related tools. Each section carries useful agent-facing information, and the complexity of a 16-parameter, 4-action tool justifies the length. A few points overlap with schema details, but the structure keeps it scannable.

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

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

For a complex tool with multiple actions, pitfalls, and permissions, the description is remarkably complete. It explains when to use each workflow, what could silently go wrong, which permissions are required, how pagination works, what the key response fields are, and which sibling tools provide supporting data. Even with an output schema present, the description still adds valuable operational context without omitting critical guidance.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful meaning beyond the schema: it explains mode IDs in human terms, warns about mode-specific pitfalls, clarifies usersList as 'DOMAIN\USERNAME' entries, and notes the default window when no end time is given. It does not restate raw parameter definitions but enriches how the parameters should be used.

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

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

The opening sentence names a specific verb and resource: 'Query ThreatLocker maintenance mode history for computers.' It clearly differentiates the tool's history-focused purpose and later lists mode types, workflows, and related tools. However, the tool also supports enable/end/update_end_time actions, and the description never explicitly states those mutation capabilities as part of its purpose; they are only implied through pitfalls and the schema.

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

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

The description provides concrete common workflows ('View maintenance history for a computer', 'Audit who put computers in installation mode') and points to related tools for complementary tasks: computers for IDs/current mode and computer_groups for group-level modes. It does not explicitly explain when to choose this tool over others or when not to use it, so it stops short of a 5.

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

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

Annotations already signal read-write behavior (readOnlyHint=false), and the description adds useful operational context: permissions, pagination behavior, enum meanings for direction/policyActionId, and parent-org tag formatting. It does not disclose any create-side effects or deployment nuance, and the 'Query' framing downplays the mutation capability, so it is not a 5.

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

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

The description is clearly organized into definition, common workflows, pitfalls, permissions, pagination, key response fields, and related tools. It is long but every section earns its place given the tool's 20-parameter, three-action surface area, and the opening sentence is direct.

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

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

For a complex tool with 20 parameters, an output schema, and annotations, the description covers read workflows, filtering, pagination, permissions, and key pitfalls. The notable gap is that create is not represented in the common workflows or prose, leaving the mutating path to be inferred from the schema enum description alone.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds genuine value beyond the schema by explaining tag label/id resolution, the 'ParentOrg\TagName' format, direction/policyActionId mappings, appliesToId lookup via computer_groups, and fetchAllPages behavior.

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

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

The description clearly names the resource ('ThreatLocker network access control policies') and the primary read verb ('Query'), and it differentiates from sibling tools by noting 'Related tools: policies (application control policies)'. However, the tool's schema supports create as a first-class action, and the description's 'Query' opening plus common-workflow list only cover list/get, so the full purpose is understated.

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

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

The 'Common workflows' section gives concrete invocation patterns (action=list, searchText, appliesToId, action=get) and the pitfalls section tells agents about no-Global-level and tag-format constraints. It stops short of explicit 'use policies for application-control instead' routing, though the 'Related tools' line does clarify the sibling division.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context: listing is paginated, fetchAllPages can auto-fetch up to 10 pages, the action parameter is currently limited to list, and View Computers permission is required. This goes beyond the annotations without contradicting them.

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

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

The description is well-organized with a short summary, bulleted workflows, permissions, pagination notes, key response fields, and related tools. It is longer than the minimum but every section adds operational value; only minor redundancy exists between 'currently connected' and 'active endpoints'.

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

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

For a read-only list tool, the description covers what the tool does, when to use it, permissions, pagination behavior, useful response fields, and related alternatives. The output schema handles return-value specifics, so nothing essential is missing for an agent to invoke the tool correctly.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds practical parameter semantics by demonstrating action=list, pageNumber=2, pageSize=100, and fetchAllPages=true in realistic workflows, which helps an agent select parameters meaningfully beyond the raw schema definitions.

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

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

The description clearly identifies the resource (ThreatLocker online devices), the operation (query/list), and the outcome (devices currently connected and reporting). It distinguishes itself from related tools by noting computers is for full inventory with details and computer_groups is for membership structure.

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

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

Provides explicit common workflows with concrete examples, including checking online count, verifying a specific hostname, monitoring fleet connectivity, and paginating large lists. It also names related tools and their different purposes, giving the agent clear guidance on when to choose this tool versus alternatives.

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

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

The description goes far beyond the annotations by specifying what the destructive rotation does ('invalidates the old key and breaks existing deploy scripts'), what get_auth_key returns, pagination fetching behavior, required permissions, and key response fields. This gives the agent concrete behavioral expectations for each action.

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

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

The description is long but exceptionally organized with labeled sections: workflows, pitfals, permissions, pagination, response fields, and related tools. Every section earns its place and adds operational value; the most critical workflow snippets are listed early.

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

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

For a complex tool with 21 parameters and six actions, the description covers workflows, destruction warnings, permissions, pagination, response fields, and sibling-tool relationships. An output schema exists, and the description correctly avoids redundant return-value explanation while providing complementary operational context.

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

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

With 100% schema description coverage, the baseline is 3, and the description adds meaningful workflow context around parameters (e.g., timezoneId must come from action=timezones, name mismatches create duplicates, fetchAllPages vs pagination). It does not need to re-explain every parameter because the schema already covers them, but the action-to-parameter orchestration is valuable.

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

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

The description clearly identifies the tool as the entry point for ThreatLocker organizations and enumerates the distinct actions it supports (list_children, get_auth_key, create_child, etc.). It also defines organizations as top-level containers and distinguishes this tool from siblings like computers, computer_groups, and policies, so an agent can select it confidently.

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

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

It provides explicit common workflows with exact action values and parameter examples, such as listing children with searchText and creating a child org with timezoneId. It also states pitfals, pagination behavior, permissions, and related sibling tools, giving clear when-to-use and when-not-to-use guidance.

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

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

The description goes well beyond the annotations: it discloses that update is a full-replace requiring get first, that changes must be deployed, that precedence is first-match-wins, that monitorMode=1 overrides Learning Mode, and that the implementation is payload-verified but not live-tested. These are non-obvious behavioral traits that materially affect safe invocation and are not conveyed by annotations alone.

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

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

The description is long but topically organized and mostly dense. It earns its length given 46 parameters and 8 actions. However, the full-replace warning is effectively given three times: in the workflow bullet, in the 'IMPORTANT' callout, and again in the Pitfalls section. This redundancy prevents a 5.

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

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

For a complex, mutating tool with 46 parameters and many actions, the description covers workflow examples, pitfalls, scoping constraints, permissions, pagination, key response fields, and related tools. An output schema exists, so return-value documentation is not required here, and what is included is sufficient for an agent to select and invoke the tool correctly in most scenarios.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning: it maps each action to its required parameters, gives concrete example values, explains conditional validity constraints (e.g., allowRequest and killRunningProcesses are Deny-only, ringfencing requires policyActionId=6), and warns about full-replace behavior for nested arrays on update. This is genuinely valuable beyond the property descriptions.

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

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

The description opens with 'Manage ThreatLocker policies' and then immediately defines a policy as linking an application (set of file rules) to a computer group with an action. This makes the specific object and domain clear, and the explicit comparison between list_all and list_by_application plus the 'Related tools' section distinguishes it from sibling tools such as network_access_policies and storage_policies.

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

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

The description explicitly says when to use list_all vs list_by_application, provides a set of common workflows with required parameters per action, and adds critical routing guidance such as 'After create/update/delete/copy, deploy changes with action=deploy'. Alternatives like applications, computer_groups, and action_log are named and their role in the policy workflow is stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false; the description adds that reports are aggregated views and requires 'View Reports' permission, plus notes reportData is dynamic. No contradiction exists, and the added context about permission and aggregation goes beyond what annotations alone convey.

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

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

The description is front-loaded with a one-sentence purpose, then uses compact bullet-style workflows. Every section earns its place, though 'Export data for external analysis' is somewhat obvious; still, clarity and structure are strong.

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

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

With an output schema present and annotations covering safety, the description supplies the remaining selection context: permissions, related tools, key response fields, and planned workflows. An agent can navigate list/get_data and know when to choose a sibling tool. Complete for this complexity.

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

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

All parameters are described in the schema (100% coverage), so the baseline is 3. The description's workflows add meaning by showing how action and reportId relate (list first, then get_data) and indicating the report window defaults and output format, going slightly beyond the schema.

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

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

The description opens with 'Query and run ThreatLocker reports,' a specific verb+resource combination, and clarifies it covers pre-built and custom reports. It distinguishes from siblings via the 'Related tools' line and the aggregation focus, so an agent can tell reports from raw audit or device inventory tools.

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

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

The 'Common workflows' section explicitly maps actions to tasks (list, get_data, export) and instructs to get reportId from the list action first. It lists related tools like action_log and system_audit for raw events/trail, implying this tool is for aggregated views, though it never explicitly states when not to use this tool.

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

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

The description goes well beyond the annotations by disclosing verified failure modes (opaque 500 on malformed searchData, 'Page type wasn't found' for invalid saveSearchPageId), requiring a fresh GUID for insert, and noting the round-trip requirement for saveParameters. This gives an agent concrete expectations for what happens and what to avoid.

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

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

The description is well-structured with workflows, pitfalls, permissions, and related tools. There is minor redundancy (saveParameters is described in both the intro and the pitfalls), but the extra length is justified by the complexity and risk of the operations.

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

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

With an output schema present, the return format does not need to be explained. All operational prerequisites, failure modes, required parameters per action, and related tools are covered, making the description complete 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.

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

Although the schema already covers all 12 parameters, the description adds critical operational semantics: valid saveSearchPageId range (1-10), the requirement to generate a new saveSearchId for insert, that searchData must be valid JSON and is server-side deserialized, and that saveParameters comes from action_log. These details materially improve correct invocation.

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

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

The description states a specific resource ('saved Unified Audit / investigation searches') and the three concrete operations (list, insert, delete) that make up 'manage'. It distinguishes the tool from siblings by naming the action_log relationship and by scoping the resource to saved searches rather than audits or policies.

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

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

The description gives explicit workflows for list, save, and delete, including exact parameter mappings for each workflow. It also names the related tool (action_log) and states when to use it (build_search_string produces saveParameters), plus the required permission.

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

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.

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.

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.

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.

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.

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.

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that no public write endpoint exists, that policies evaluate first-match top-down with permits above denies, lists required permissions, states pagination behavior, and notes key response fields. This is rich behavioral disclosure with no contradiction.

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

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

Well structured with a clear summary line, common workflows, pitfalls, permission/pagination notes, and related tools. Content is front-loaded and every bullet adds operational value without redundant filler.

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

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

For a 10-parameter tool with annotations and an output schema, the description covers usage workflows, domain semantics, limitations, permissions, pagination, and key response fields. Nothing essential seems missing for correct selection and invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful parameter usage patterns with examples for `action`, `searchText`, `appliesToId`, `storagePolicyId`, and `fetchAllPages`, plus a caveat about `policyType` not being documented in public KB. This exceeds the baseline.

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

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

The description opens with a specific verb and resource: 'Query ThreatLocker storage control policies.' It clearly ties policies to file/folder access on storage locations and explicitly distinguishes from `policies` as application control policies in the Related tools section.

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

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

Provides concrete common workflows for list/get, search, filtering, and pagination, and names `policies` as the related sibling with a parenthetical distinction (application control vs storage control). It doesn't explicitly say when NOT to use this tool or give contrastive conditions, but the context is strong enough for an agent to select correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context: required permissions, pagination behavior with max pages, wildcard support, audit action semantics, and key response fields. This goes well beyond the structured annotation data and helps the agent predict side effects and invocation constraints.

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

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

The description is well-structured and front-loaded with a clear purpose, followed by a helpful common-workflow section and concise enum/pagination/permission notes. It is longer than minimal but every section earns its place; only minor redundancy with the schema's parameter descriptions prevents a perfect score.

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

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

For a 16-parameter tool with two distinct actions, the description is exceptionally complete: it covers both actions, provides concrete usage patterns, explains the key enum values, notes pagination and fetchAllPages, lists required permissions, identifies key response fields, and points to related tools. Since an output schema exists, return-value detail is not required. Nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description adds extra meaning through examples (e.g., auditAction=Logon with effectiveAction=Denied for failed logins) and clarifies the audit action enum values (Create, Delete, Logon, Modify, Read) and wildcard usage. It doesn't fully compensate for every parameter's nuance, but it meaningfully augments the schema.

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

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

The description opens with a specific verb and resource: 'Query ThreatLocker portal audit logs' and immediately clarifies what system audit tracks (administrator actions like logins, policy changes, approvals, configuration modifications). It explicitly differentiates itself from action_log, which tracks endpoint events, so an agent can distinguish this tool from its siblings without ambiguity.

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

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

The description gives explicit when-to-use guidance with common workflow examples for both actions (search and health_center), names the related tool action_log as the alternative for endpoint events, and states required permissions (View System Audit, View Health Center). It also explains pagination behavior, making it clear when fetchAllPages should be used.

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

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

The description is rich in behavioral detail: full-object replace semantics, 'get first, resend ALL item arrays you want to keep', no insert/delete endpoint, parent-organization naming format, pagination, and permissions. These details go far beyond the annotations and help the agent avoid data loss; no contradiction with annotations exists.

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

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

The description is well-organized with headers, workflows, pitfalls, permissions, and key fields, and it fronts the action patterns. It is long, but the 16-parameter surface justifies it; there is minor redundancy in the parent-tag naming format being stated twice.

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

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

Given the complexity (16 parameters, multi-action dispatch, mutable update semantics), the description covers workflows, prerequisites, pitfalls, permissions, key response fields, and related tools. An output schema exists, so the lack of a full return spec is acceptable; the description is complete enough for correct invocation.

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

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

Schema coverage is 100%, but the description still adds workflow-level semantics: parameter combos for each action, the prerequisite of dropdown before get/update, full-replace behavior of item arrays, and the need for organizationId on update. This materially helps correct parameter selection beyond the schema itself.

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

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

The description clearly identifies the resource (ThreatLocker tags) and enumerates the exact actions (dropdown, get, update) with common workflows, so an agent can tell what the tool does. It slightly understates scope by opening with 'Query' when a full-object-replace update is also a core operation, but the body immediately corrects that.

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

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

Common workflows act as usage guidance: 'List all available tags: action=dropdown', 'Update tag membership: action=update, tagId=..., organizationId=...'. It gives clear contextual advice such as using dropdown to obttain tagId for policy payloads, though it does not explicitly state when not to use this tool versus a sibling.

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

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

Discloses important behavioral caveats beyond annotations: the field casing quirk 'shA256', the need for a fresh GUID on insert, and 'Writes are payload-verified, NOT live-tested.' Annotation contradictions: false; readOnlyHint=false is consistent with write operations.

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

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

Well-structured with 'Common workflows', 'Pitfalls', and 'Permissions' sections. Every sentence adds value, and key constraints are front-loaded before peripheral options.

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

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

Given the 10 params, output schema, and annotations, the description covers the core actions, required fields, critical pitfalls, permissions, and related tools. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, but the description adds workflow-level meaning: which parameters are required for insert vs get, the new-GUID requirement for uploadRequestId, and the shA256 casing pitfall. This enriches the schema without duplicating it.

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

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

Description clearly states the verb + resource: 'Request and retrieve forensic file uploads from endpoints.' It explicitly distinguishes the two core actions (insert vs get) and is clearly differentiated from related siblings like action_log and approval_requests.

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

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

Provides explicit common workflows with exact action values and required parameters ('action=insert, uploadRequestId=<new GUID>...'), plus related tools for supporting context (action_log for locating events, computers for computerId). It also states permissions needed, giving clear guidance on when and how to use the tool.

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

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

Annotations already cover readOnly, openWorld, idempotent, and non-destructe behavior. The description adds useful context: permissions required, response fields, and the claim 'No pagination — returns all versions in a single response.' However, that claim is in tension with the fetchAllPages parameter in the schema, which makes the behavioral guidance slightly inconsistent.

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

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

The description is well-organized into summary, workflows, permissions, pagination, response fields, and related tools; every section serves a purpose. Minor repetition of 'action=list' in each workflow bullet pads the text slightly, but it remains easy to scan.

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

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

With an output schema present and strong annotations, the description does not need to explain return values, yet it still enumerates permissions, no-pagination behavior, key response fields, and common workflows. The only notable gap is the ambiguity between the 'No pagination' statement and the fetchAllPages parameter, which an agent would need to reconcile before calling.

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

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

Schema description coverage is 100%, with clear enum/default/description for every parameter, so the baseline of 3 applies. The description reinforces action=list and lists key response fields, but it adds little parameter-specific meaning beyond the schema. The 'No pagination' note also mildly conflicts with the fetchAllPages parameter, preventing a higher score.

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

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

The description opens with 'Query available ThreatLocker agent versions,' a clear verb and resource, and then specifies what is returned: enabled versions, default version, and release dates. It also references related tools and workflows, helping distinguish it from siblings like computers and computer_groups.

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

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

The 'Common workflows' section gives concrete scenarios with action=list, such as finding the latest version, checking availability, and identifying defaults. It also points to related tools like computers for installed versions and scheduled_actions for updates, though it stops short of explicit 'use X instead' exclusions.

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