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

With no annotations, the description carries the full behavioral burden and does well: it discloses that it contacts only this project's GitHub releases (network scope), that it works even when the knowledge base is not built, and what not_ready conveys. It still omits whether the call is cached, rate-limited, or purely read-only, so it falls short of a complete behavioral picture.

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?

Front-loaded with the core purpose, then the network scope, then the action/return contract. The enumeration is dense but every clause maps to a real behavior or routing decision; only the nested parenthetical about build_locally is slightly heavy.

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?

No output schema exists, so the description must describe the return contract, and it does: action, reason, not_ready, and upgrade_to. Together with the edge-case note about running before a knowledge base is built, an agent has everything needed to call it and react to its result.

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 tool takes no input parameters, so there is nothing to document; per the baseline, a 0-parameter tool scores 4. The description correctly spends no space on nonexistent inputs.

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?

States a specific verb and resource: check whether a newer prebuilt knowledge base is published than the one installed. It also scopes the network call to this project's GitHub releases, so an agent knows exactly what this check touches, distinct from siblings like install_knowledge_base or list_stigs.

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 enumerates every outcome of action (install, upgrade_package, build_locally, none) and routes each to the concrete next step, naming install_knowledge_base, upgrade_to, and the stig-mcp-fetch/stig-mcp-ingest path. This is explicit when/when-not guidance tied to alternatives rather than inference.

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?

With no annotations, the description carries the full burden and does so well: it discloses the 50-id cap, release-specific matching semantics, that a shared V- id returns every match labeled by benchmark, that unmatched ids land in not_found, that an all-miss call is refused with an error, and that an unbuilt knowledge base returns {"status": "not_ready"} with commands instead of erroring.

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?

Dense but front-loaded: purpose first, then id semantics, then edge-case behavior. Every sentence carries information, though the id-format and labeling guidance makes it longer than a minimal description.

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?

No output schema and no annotations, so the description must cover returns and edge cases; it names the returned fields (check/fix text, benchmark, release, CCIs), the not_found list, the error-on-no-match path, and the not_ready path. Nothing an agent needs to call this 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 description coverage is 0%, so the description must compensate, and it does: it defines the accepted id forms (SV-...r..._rule and V-), the 50-item limit, the matching behavior per form, and the preferred form. This adds far more meaning than the bare `ids: array of string` 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?

States a specific verb and resource: returns DISA's check and fix text for STIG findings, plus each finding's benchmark, release and CCIs. This is clearly separable from siblings like mitigations_for_technique and list_stigs, which serve different lookups.

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?

Explains where the ids come from (findings under a mitigations_for_technique or techniques_for_actor answer) and gives an explicit preference rule (prefer V- over rule ids, since a rule id matches only its release). It stops short of stating when to avoid this tool entirely, but the routing guidance is clear.

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?

With no annotations, the description carries the full burden and does so well: it discloses network dependency ('uses the network'), approximate size and duration ('about 5 MB and can take several seconds'), the SHA-256 verification step, the rollback mechanism via 'release pins an exact kb-YYYY-MM-DD tag', and the no-network branch. This is unusually rich behavioral context for an install/mutate operation.

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?

Every sentence contributes information — download source, verification, size/latency, offline path, trigger conditions — and the primary action is front-loaded. It is somewhat dense and reads as one continuous block rather than clearly separated modes, which costs a point.

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 no-annotation, no-output-schema, 3-parameter tool, the description covers inputs, network behavior, verification, and invocation triggers thoroughly. It does not mention what a successful invocation returns or how failures surface, a minor gap given there is no output schema to lean on.

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 0%, so the description must compensate, and it does: 'release pins an exact kb-YYYY-MM-DD tag, for rollback'; 'path (a .sqlite.xz or .sqlite copied from a release)'; 'sha256 (the value its SHA256SUMS lists)'. Each of the three parameters gets format and purpose beyond the bare 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 states a specific verb and resource ('Install the prebuilt knowledge base this server answers from') and immediately scopes the default behavior (download newest release, verify SHA-256, install). It also differentiates itself from siblings by noting it is 'the only tool besides check_sources that uses the network.'

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 trigger conditions: 'Call this when another tool returns {"status": "not_ready"}, or when check_sources reports "install".' It also names the conditions under which the offline parameters apply ('On a host without network access, pass path ... and sha256'). Both when-to-use and when-to-use-the-alternative-mode are covered.

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?

No annotations are provided, so the description carries the full burden. It adds genuine behavioral value by disclosing the not-ready state return ({"status": "not_ready"}) instead of an error, but says nothing about permissions, pagination, or the shape/ordering of the returned STIG list.

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?

Two sentences, front-loaded with the core purpose and followed by the edge-case behavior. 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?

For a single-param, no-output-schema list tool this is nearly complete: purpose, filter semantics, and the not-ready edge case are all covered. Only the return format of a successful call (fields, ordering, size) is left unspecified.

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 0% and the single 'filter' param is undocumented in the schema, so the description must compensate. It does, explaining that the filter is a substring match against title, benchmark id (with a concrete example, RHEL_9_STIG), or product keywords — meaning the schema alone does not provide.

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?

States a specific verb (List) and resource (STIGs in the knowledge base) and scopes it by the filter dimensions. An agent can immediately distinguish this read/list tool from siblings like search_techniques or mitigations_for_technique.

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 implies usage through the filtering options (title substring, benchmark id, product keywords) but never states when to prefer this over siblings or any prerequisite workflow. It does tell the agent what happens when the KB isn't built, which is useful context, but no explicit when/when-not guidance is given.

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?

With no annotations, the description carries the full burden and does so: it discloses the response envelope (summary, rules found, cat_i, controls_with_rules), that findings lack check/fix text, that revoked techniques are redirected and reported via technique.redirected_from, and that an unbuilt KB returns {"status": "not_ready"} instead of an error.

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?

Front-loaded with purpose, then response shape, then parameter guidance. Dense but nearly every sentence adds a distinct behavioral fact; the length is justified by the amount of non-obvious behavior it must convey, though it could be tightened slightly.

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?

No output schema or annotations exist, yet the description sketches the return structure, the redirect field, and the not_ready case, which is everything an agent needs to call and interpret this tool.

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 0%, so the description must compensate, and it documents all four: severity's CAT-level semantics with an example, stig_ids' cap and intended use, system_description's build string format with an ESXi example and rationale, and technique_id's redirect 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?

States a precise verb+resource pair ('Return 800-53r5 controls and the DISA STIG findings that mitigate an ATT&CK technique') and distinguishes itself from the sibling finding_details by naming what it does not return (check/fix text). An agent can tell exactly what this produces.

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?

Gives explicit routing rules: use finding_details for exact DISA steps, pass system_description when you cannot name a system, use stig_ids only for benchmarks you already know. It also states the 200-item cap and what severity accepts, so the agent knows when each parameter applies.

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?

With no annotations, the description carries the full burden and discharges it: it explains the limit semantics (caps distinct benchmarks, not rows, and can yield more rows than limit), the 'applicable' field, the tie-overflow note, and the not_ready status with remediation commands instead of an error. This is unusually rich operational disclosure.

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?

Purpose and return shape are front-loaded, and each sentence carries information. It is dense and runs long, with the tie-note and multi-part-note behavior occupying separate sentences that could be tightened, but nothing is 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?

No output schema exists, so the description must describe returns itself; it names 'candidates', 'notes', the 'applicable' field, and the not_ready shape. For a 2-parameter lookup tool with no annotations, everything an agent needs to call and interpret it is present.

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 0%, so the description must compensate and does: limit is explained in depth (benchmarks vs rows, multi-major benchmarks contributing several rows), and system_description gets guidance on including build strings and how multi-system input is parsed. Both parameters gain meaning beyond their bare schema titles.

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 states a specific verb (resolve) and resource (free-text system description → candidate DISA STIGs), and the tool is clearly distinguishable from siblings like list_stigs or search_techniques. An agent can tell what it returns ('candidates' and 'notes') without opening any 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?

It gives strong input-shaping advice (include the product build, multi-system descriptions are split on 'and'/commas) but never states when to prefer this over list_stigs or another sibling, nor any explicit when-not-to-use condition. Usage is implied rather than contrasted against 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?

With no annotations, the description carries the full burden and does well: it discloses that revoked ids/names still match and return a replacement with redirected_from set, and that an unbuilt knowledge base yields {"status": "not_ready"} with commands rather than an error. It does not mention pagination, result caps, or auth needs, so it is not exhaustive.

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?

Three tight sentences, each earning its place: the core purpose first, then revoked-id behavior, then the not-ready edge case. No 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?

With no output schema and no annotations, the description covers the important edge cases (revoked techniques, unbuilt knowledge base) well. It is only slightly incomplete in not describing the 'limit' parameter or the shape of successful results.

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 0%, so the description must compensate. It adds real meaning for 'query' (matches by name or id, including revoked ids), but 'limit' (default 10) is never explained and no query syntax or matching semantics are given.

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?

States a specific verb (search) and resource (ATT&CK techniques) plus the matching keys (name or id). It is clearly distinct from siblings like mitigations_for_technique or techniques_for_actor, but it never names or contrasts those siblings explicitly, so it falls short of a 5.

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 purpose implies when to use it, but there is no explicit when/when-not guidance and no routing to alternatives such as techniques_for_actor or mitigations_for_technique. Usage is left to be inferred from the verb.

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?

With no annotations, the description carries the full burden and does so: it discloses actor-matching normalization (case, spacing, punctuation, trailing Group/Team), matched_as/also_matches behavior, that misspellings are not auto-corrected, and the exact not_ready return shape instead of an error. It also explains the response structure and control-id provenance grouping.

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?

Dense but front-loaded, leading with purpose and expansion option before edge cases. Every sentence carries information, though the middle section is packed and could be broken into clearer chunks.

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?

No output schema or annotations exist, so the description must explain both behavior and return shape, which it does (summary counts, controls, findings, per-technique control ids by source). An agent has everything needed to call it and interpret the result.

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 0%, but the description gives meaning to all five parameters: actor accepts id/name/alias with fuzzy matching rules, severity takes CAT levels like ["I"], stig_ids is capped at 200, system_description scopes an unnameable system, and include_mitigations gates the other two. This fully compensates for the empty 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+resource ('List an ATT&CK actor's techniques') and immediately states the expansion option. It distinguishes itself from siblings by name, noting that mitigations_for_technique gives the same counts and that finding_details should be called for check/fix text.

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?

Explicit when-to-use guidance for nearly every branch: include_mitigations activates severity/stig_ids, system_description is the fallback for unnameable systems, and a misspelled actor should be retried with the closest group id. It even states the not_ready path and its remedy.

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