agent-bom

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

The description explains that listing/fetching recomputes and persists status, making it an idempotent write—this adds behavioral context beyond the annotations (idempotentHint=true, readOnlyHint=false). It discloses the side effect and distinguishes this from true read-only 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?

The description is concise (2-3 sentences) and front-loaded with the core purpose, followed by details on behavior and excluded actions. Every sentence is essential and no extraneous information is present.

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 tool has 3 parameters, annotations, and an output schema, the description adequately covers the primary functions, side effects, and limitations. It is complete enough for an AI agent to use correctly. Could potentially mention required permissions or authentication, but not necessary for core functionality.

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. The description adds value by explaining the usage pattern (omit campaign_id to list, provide to fetch one) and the effect of the limit parameter, enhancing the semantic understanding beyond the schema alone.

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 states the tool lists or gets NHI access-review campaigns, specifying two modes: listing (omit campaign_id) and fetching one (with campaign_id). The verb and resource are specific and the purpose is unambiguous.

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 guidance on when to use each mode (with/without campaign_id) and clearly states what the tool does NOT do (creating campaigns or submitting decisions), which helps the agent avoid misuse. However, it does not explicitly name alternative tools for excluded actions.

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, destructiveHint=false, etc. Description adds no further behavioral details (e.g., no mention of scanning depth, file types, or output structure). Adequate but basic.

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?

Single sentence, no redundant information, front-loaded with key verb and resource. Every word 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?

Despite having an output schema, the description is minimal and does not elaborate on what 'AI component usage patterns' entails. Could benefit from a brief list of scanned elements (e.g., SDK imports, model refs) already partially in parameter description but not in tool description itself. Adequate for simple tool but not comprehensive given numerous siblings.

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?

Input schema already fully describes the 'directory' parameter with 100% coverage. Tool-level description adds no extra parameter meaning beyond the schema's rich description.

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 verb ('scan') and resource ('source code for AI component usage patterns'). Distinguishable from sibling tools like code_scan or prompt_scan by focusing specifically on AI component usage.

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?

No guidance on when to use this tool versus alternatives such as model_file_scan or inventory. Does not mention prerequisites or typical scenarios.

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 fully cover safety (readOnlyHint, idempotentHint) so the description need not repeat those. It adds context about the AISVS standard but no additional behavioral traits beyond what annotations provide.

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 a single concise sentence that front-loads the key purpose. Every word contributes value; there is no fluff 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 simple tool with one optional parameter and good annotations, the description is nearly adequate but omits the default behavior (all 9 checks) and does not reference the output schema or differentiate from similar sibling tools.

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 only parameter 'checks' has a complete description in the schema (100% coverage). The tool description does not add any extra meaning beyond the schema, which already explains the comma-separated IDs and default 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 states the tool runs AISVS v1.0 compliance checks, using a specific verb and standard. It distinguishes from siblings like cis_benchmark by naming a different standard.

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?

No guidance is provided on when to use this tool versus alternatives like compliance, check, or cis_benchmark. The description lacks when/when-not criteria or references to sibling tools.

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, destructiveHint=false, and idempotentHint=true. The description adds value by disclosing the setup requirement and the potential for empty results when ClickHouse is not configured. 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 extremely concise with two sentences: first for purpose, second for prerequisites and behavior. It is front-loaded and contains no wasted words.

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?

An output schema exists, so return values are likely documented. The description covers prerequisites and a failure mode. Parameter schema thoroughly documents each parameter and its context. Together, these provide sufficient completeness for a query tool. Slight miss: not all query types are explicitly listed in the description, but they are in the schema.

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% and parameter descriptions are detailed (e.g., listing which query types use each parameter). The description does not add significant meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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 states the verb 'Query' and the resources 'vulnerability trends, posture history, and runtime event summaries from ClickHouse.' This distinguishes it from sibling tools like audit_query or intel_lookup, which query different data sources. The parameter schema further lists all query types, reinforcing specificity.

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 a prerequisite ('Requires AGENT_BOM_CLICKHOUSE_URL to be set') and a fallback behavior ('Returns empty results if ClickHouse is not configured'). However, it does not explicitly guide when to use this tool over alternatives such as audit_query or intel_lookup, which also query data but from different sources.

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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, so the description's claim of 'surface' and 'proactive detection' aligns and adds context that the tool is analytical and non-destructive. No behavioral details are missing or contradictory.

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 a single, well-structured sentence that immediately conveys the tool's purpose and output. No extraneous words or redundant 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 tool's simplicity (2 parameters, no required parameters, output schema exists), the description sufficiently defines purpose and use case. It could optionally mention that results include flagged outliers, but the output schema likely covers that.

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%, and the schema already contains clear parameter descriptions ('Z-score threshold...', 'Tenant scope...'). The tool's description does not add any further parameter semantics beyond what the schema 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 uses a specific verb ('Surface') and clearly identifies the resource ('cost and behavior anomalies'), specifying the kinds of anomalies (per-agent spend, per-session tool-call-rate statistical outliers) and the purpose (proactive runaway-agent detection). This clearly distinguishes it from sibling tools like 'cost_report' or 'tool_risk_assessment'.

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 for proactive detection of runaway agents, but it does not explicitly state when not to use it or provide alternatives. Given the large set of sibling tools, a note on when to prefer this over other scan tools would be beneficial.

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 disclose destructiveHint=true, so the description's 'activate' aligns but adds little detail. It does not explain side effects, reversibility, or the audited nature of the write (though parameters mention 'audited write'). The 'canonical lifecycle store' phrase adds no behavioral context. Since annotations carry most of the burden, and the description contributes minimal additional disclosure, this is below baseline.

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 a single, short sentence that states the main action upfront. The inclusion of 'through the canonical lifecycle store' is somewhat redundant but does not bloat it materially. It is concise and structured acceptably, though it could be more informative without adding length.

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 having an output schema and 100% parameter coverage, the description is inadequate for a destructive write operation. It omits the domain (vulnerability exceptions), the expected workflow (request -> approve), prerequisites, and any caveats. The sibling list includes closely related tools like 'request_exception' and 'list_exceptions', and this description does not clarify how it fits. Two sentences of context could dramatically improve completeness.

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 documents all five parameters. The description does not add any extra meaning to parameters like 'exception_id' or 'reason'. It implicitly relates to approving an exception but adds no syntax or usage nuance. Because coverage is high, the baseline of 3 applies; the tool does not need the description to compensate.

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 uses a specific verb 'activate' with a resource 'pending exception', which clearly indicates the action. It distinguishes from siblings like 'request_exception' (creating) and 'list_exceptions' (listing), though the phrase 'canonical lifecycle store' is vague jargon that obscures the actual domain (vulnerability exceptions) and may confuse an agent.

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 no guidance on when to use this tool versus alternatives. It does not mention that it operates on exceptions created via 'request_exception', nor when it should be avoided (e.g., for already-active exceptions). An agent is left to infer the workflow from the name and siblings with no explicit conditions.

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 provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the description need not restate those. It adds value by specifying the scope (control-plane and runtime), which gives useful context beyond 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 a single, front-loaded sentence with no redundant words. It is appropriately sized and efficiently conveys the core purpose.

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 presence of a full schema and an output schema, the description is mostly sufficient. However, it could benefit from clarifying what 'integrity' means (e.g., hash verification) to fully cover the tool's behavior, but it is still above minimal.

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 fully documents each parameter. The description adds no additional meaning or guidance for parameter usage, meeting the baseline of 3.

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 uses a specific verb 'Verify' and clearly identifies the resource 'control-plane and runtime audit chain integrity'. It effectively distinguishes from sibling tools like 'audit_query' which likely queries logs rather than verifying integrity.

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 does not explicitly state when to use this tool versus alternatives (e.g., 'audit_query'). It implicitly suggests it is for integrity checks, but lacks explicit context or exclusions, making it minimally informative for tool selection.

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 indicate readOnlyHint=true, destructiveHint=false. The description adds context that the audit log is immutable, hash-chained, and that the tool never mutates enforcement state. This enriches the behavioral understanding beyond 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 front-loaded with the main purpose and well-structured, but the Args section is somewhat verbose and repeats schema details. Still clear and logically organized.

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 presence of an output schema and detailed annotations, the description sufficiently covers purpose, usage, filtering, paging, and pairing with audit_integrity. No gaps for an agent to misuse the 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 100%, so the description's Args section mostly repeats schema descriptions without adding new meaning or constraints. Baseline 3 is appropriate as the schema already documents parameters well.

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 states it reads tenant-scoped control-plane audit records with filters and paging, and distinguishes itself from the sibling tool audit_integrity by specifying that it is for reviewing changes while integrity verification is separate.

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 guidance is provided: 'Call this to review who changed what in the control plane; pair with audit_integrity to verify the chain has not been tampered with.' This tells when to use and suggests an alternative for verification.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: the fallback to a local MCP configuration scan, the explicit labeling of that narrower source, and the `found=false` return case. 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 concise (~100 words), front-loaded with the primary action, and structured with Args and Returns sections. Every sentence earns its place: the two behavioral notes (persisted vs. local source) and the return format are all useful. No redundancy or fluff.

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 lookup tool with strong annotations, a 3-param schema at 100% coverage, and an output schema, this description is complete. It covers purpose, two distinct operational modes, parameter requirement (cve_id), and a not-found outcome. The output schema presumably handles return-field details, but the description already gives the key returning fields.

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 each parameter (cve_id, scan_id, tenant_id) has a description. The description's Args section only restates cve_id syntax ('e.g. CVE-2024-1234 or GHSA-xxxx') without adding new semantics. Per the calibration baseline, 3 is appropriate.

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+resource+scope: 'Look up the blast radius of a specific CVE across your AI agent setup.' It clearly distinguishes this from siblings like exposure_paths and intel_lookup by focusing on CVE-specific blast radius. The two data-source modes (persisted control-plane evidence vs. standalone local scan) are also explicitly described.

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 clear behavioral context: it reads persisted evidence when available and falls back to a local scan in standalone mode, labeling the narrower source explicitly. However, it does not explicitly name alternative tools or say when not to use this tool, so it stops short of a full when/when-not guideline.

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 and idempotentHint. The description adds context about scanning for 'dangerous permissions' but does not elaborate on what that means or how it behaves.

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?

A single sentence with no extraneous words, immediately conveying the tool's purpose.

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 low complexity (1 param, output schema present) and annotations, the description is sufficient for an agent to understand the tool's primary function, though it could hint at expected output format.

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% coverage with a description for the only parameter. The tool description adds no additional parameter information 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 clearly states the action ('Scan') and the resource ('installed browser extensions') with a specific focus ('dangerous permissions'). This distinguishes it from sibling tools like code_scan or fleet_scan.

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 for scanning browser extensions but provides no explicit guidance on when to use or avoid this tool, nor does it mention 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is covered structurally. The description adds genuine value by disclosing the external dependency on OSV.dev (an outbound network query) and documenting the JSON return shape. No contradiction 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 key purpose is front-loaded in the first line, followed by a tight context sentence and structured Args/Returns blocks. It earns its length with the OSV.dev source note, usage guidance, and return-format disclosure, with 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?

Given rich annotations, an output schema, and 100% parameter coverage, the description covers what matters beyond structure: external data source, when to invoke, and expected return fields. The only minor gap is that the offline/version parameters are not surfaced in the description text, though the schema fully documents them.

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 all four parameters are already documented structurally and the baseline is 3. The description reinforces package/ecosystem with concrete examples but omits the offline and version parameters entirely from its Args section. It adds convenience, not new meaning, on top of 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 precise 'Check a specific package for known CVEs before installing' — a specific verb, resource, and scoping constraint. It clearly separates this single-package advisory check from broad siblings like scan or registry_lookup by framing it as a targeted, pre-installation safety verification.

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?

'Use this before installing an MCP server or dependency to verify it is safe' gives an explicit trigger condition and intended moment of use. However, it does not name any alternative tools or state when NOT to use it, leaving an agent to infer the boundary against scan/policy_check/marketplace_check on its own.

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 explicitly states 'All checks are read-only,' which aligns with the readOnlyHint annotation. It additionally discloses credential requirements and the inclusion of MITRE ATT&CK mappings, providing useful behavioral context beyond the annotations. No contradiction is present.

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 structured with a clear lead sentence followed by a bullet-like enumeration of benchmarks and a return format section. It is informative without excessive verbosity, though the list of check counts could be seen as slightly extraneous.

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 provides a comprehensive overview of the tool's purpose, the benchmarks it covers, the output format (JSON with pass/fail, evidence, severity, ATT&CK techniques, pass rate), and prerequisites. This is sufficient for an agent to understand expectations without an explicit output schema.

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 schema already covers each parameter with clear descriptions (e.g., provider values, env var fallbacks, check ID format). The description's top-level text does not add significant new parameter information beyond the schema, so it does not exceed the baseline of 3.

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 states 'Run CIS benchmark checks against a cloud account' with a specific verb and resource. It distinguishes from sibling tools like 'compliance' or 'policy_check' by explicitly naming CIS Foundations Benchmarks and enumerating provider-specific check counts.

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 states when to use (for CIS benchmark evaluation) and implicitly differentiates from generic compliance checks. It also notes that 'appropriate credentials' are required, which is a prerequisite. It doesn't explicitly list alternatives, but the specificity is sufficient.

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?

Description adds significant context beyond annotations: opt-in per-provider via env flags, disabled provider behavior, returns only counts and node summary, and assures no resource secrets. Complements readOnlyHint and other annotations effectively.

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 with first front-loading core purpose, second adding critical behavioral details. No filler, every sentence 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?

Given zero required params, high schema coverage, and presence of output schema, the description sufficiently explains tool behavior, return type, and configuration prerequisites. No gaps identified.

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 has 100% coverage, so baseline is 3. Description adds minimal additional meaning beyond schema descriptions (providers, region, tenant_id). The env flag opt-in is mentioned but not tied to parameters.

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 states it summarizes estate-wide cloud asset inventory with resource and identity counts, using specific verbs and outlining scope. It distinguishes from siblings like 'inventory' by referencing opt-in env flags and reference-only nature.

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?

Description implies usage for overview but lacks explicit when-to-use or when-not-to-use compared to siblings like 'inventory' or 'ai_inventory_scan'. Mentions opt-in behavior but no alternatives or exclusions.

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 thoroughly discloses behavior: it snapshots, mounts read-only, records only SBOM and redacted secret metadata, tears down temp resources, resolves credentials via the default chain (no accepted credentials), requires an admin operator, and fails closed on missing extras/credentials. It also notes idempotency key reuse. This significantly exceeds the annotation info (readOnlyHint=false, destructiveHint=true) and adds concrete details about side effects and failure modes.

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 succinct: a one-line summary followed by a detailed but focused paragraph covering critical behavior (snapshot/teardown, metadata-only, fail-closed states, credential handling). It's organized and free of fluff, though the second paragraph is a dense run-on that could benefit from bullet points for readability.

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 13 parameters and 100% schema coverage, the description adds essential behavioral context: how the scan works (snapshot, mount, teardown), security constraints (admin role, read-only credentials, never accepts credentials), fail-closed outcomes, and metadata-only secret handling. It also clarifies idempotency via key reuseikuha, covering operational semantics beyond the schema.

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?

While the schema already provides per-parameter descriptions (100% coverage), the description adds context for parameters like idempotency_key (reuses execution record), provider-specific details (location/resource group), and the overall auth model (admin operator). It clarifies the relationship between parameters (e.g., target disk, collector VM) without repeating schema text, adding practical meaning.

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 defines the tool's purpose: triggers an agentless Azure/GCP disk side-scan, capturing SBOM and secret metadata only. Its scope is distinctly specified (Azure/GCP, not AWS), and it differentiates from siblings by emphasizing the agentless, read-only, metadata-only nature and the fail-closed honest results.

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 context on when to use (triggering a scan, evaluating cloud disk state) and what it does (snapshot, mount, tear down). It lacks explicit 'when NOT to use' or alternatives, but the Azure/GCP scoping and read-only credential requirements are clear. A brief mention of the CLI-side-scan for AWS would be a nice contrast, but it's not critical.

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 the tool as read-only, idempotent, and non-destructive. The description adds useful context beyond this: requires semgrep on PATH, returns typed statuses (findings, clean, skipped, failed), and scans for CWE-classified issues. No contradictions.

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 tightly written, with the main action front-loaded and each sentence providing useful info: purpose, vulnerability classes, return status, and a key prerequisite. No wasted words.

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 presence of an output schema and 100% parameter coverage, the description covers the essential aspects: what the tool does, what it returns (statuses), and a critical dependency. It is complete for guiding 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?

Both parameters (path and config) are fully described in the schema (100% coverage), so the description doesn't need to add parameter details. It does not significantly enrich parameter meaning beyond the schema, which is adequate.

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 states it runs SAST via Semgrep on source code and lists specific vulnerability classes (SQL injection, XSS, etc.). It is specific in verb+resource but does not explicitly differentiate from sibling tools like 'scan' or 'check'.

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 for static security scanning of source code and mentions a prerequisite (semgrep on PATH), but it does not provide explicit when-to-use or exclusions relative to alternative tools.

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 valuable context about scan behavior, return structure, and the notable fact that the nist_800_53_catalog score is independently scored and NOT folded into overall_score. This goes beyond 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 structured with Args and Returns sections, front-loaded with purpose. It is somewhat verbose, especially the Returns details, given that a full output schema exists. However, the special NIST 800-53 scoring nuance justifies the length.

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 two optional parameters and an output schema, the description fully explains scope, control mapping, return structure, and the separate NIST score. It leaves no critical gaps for an agent to understand what the tool does and what it returns.

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% with descriptions for both parameters. The paragraph text essentially restates schema descriptions (config_path auto-discovers, image is a Docker reference) without adding new semantics or edge-case guidance. Baseline 3 is appropriate.

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+resource: 'Get OWASP LLM Top 10 / OWASP MCP Top 10 / MITRE ATLAS / NIST AI RMF compliance posture.' It clearly states what it does (scans MCP configurations, maps to 47 controls) and distinguishes itself from sibling tools like scan or cis_benchmark by naming unique frameworks.

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 clear context: scans local MCP configs with optional config_path or image, auto-discovers if omitted. However, it does not explicitly mention when to prefer this tool over alternatives or provide exclusions, so it falls 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds context on output structure (nodes, edges, lateral_paths) and analysis type, without contradicting annotations. It does not detail permissions or side effects, but annotations already cover safety.

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 concise (three sentences), front-loaded with purpose, and well-structured. It efficiently conveys the tool's function, modeled entities, key question, and return fields with no extraneous content.

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 tool's complexity and that an output schema exists (so return values need not be explained), the description sufficiently covers purpose, usage context, and output structure. It mentions all relevant return fields, making it complete.

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 all three parameters. The description does not add additional meaning beyond the schema, resulting in a baseline score of 3.

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 states it builds an agent context graph for lateral movement analysis, with a specific verb and resource. It distinguishes from siblings like 'blast_radius' and 'exposure_paths' by focusing on reachability between agents, servers, credentials, tools, and vulnerabilities.

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 by answering a concrete question, 'If agent X is compromised, what else becomes reachable?' but does not explicitly guide when to use this tool versus alternatives like 'blast_radius' or 'exposure_paths'.

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 indicate readOnlyHint=true, idempotentHint=true. The description adds value by stating that no prompts or responses are read, which is a privacy assurance beyond annotations. It also describes data sourcing (OpenTelemetry GenAI spans) and included outputs, enhancing transparency.

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 concise with four front-loaded sentences. Each sentence adds unique value: main purpose, data source, included outputs, and privacy note – no redundancy or fluff.

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 presence of an output schema and the tool's moderate complexity (4 optional params, LLM cost rollups), the description adequately covers the purpose, data source, and privacy. It does not detail the exact output structure, but the output schema handles that.

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% with detailed parameter descriptions. The tool description does not add additional semantics beyond what is already in the schema, so it meets the baseline of 3 without enhancement.

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 states the verb 'Return' and the resource 'chargeback / showback LLM spend rollups', specifying the dimensions (cost-center, allocation tag) and included outputs (allocation, budget posture, forecast). It also distinguishes itself from sibling tools like cost_forecast and cost_report by focusing on rollups with budget and forecast.

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 for retrieving cost allocation data but does not explicitly compare to alternatives or state when not to use. It provides clear context on what the tool returns, but lacks explicit usage guidance or exclusions.

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 annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), the description adds that the forecast never blocks and returns null on sparse history, providing valuable behavioral context.

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 concise (two paragraphs, ~60 words) and front-loaded with the main purpose, though it could be slightly more structured.

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 output schema covers return values, the description sufficiently explains the forecasting method, behavior on sparse history, and that it is reference-only, making it complete for this tool's 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema, which already documents the optional agent and tenant_id parameters.

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 states the tool projects LLM spend burn rate and budget runway for the active tenant, using specific verbs and resources that distinguish it from siblings like cost_report or cost_allocation.

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 context on usage ('Reference only', 'never blocks a call') and mentions behavior on sparse history, but does not explicitly name alternative tools or specify when not to use it.

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, destructiveHint=false, idempotentHint=true. The description adds valuable context: spend is derived from token counts on OpenTelemetry spans and no prompts/responses are read, revealing data source and privacy assurances beyond 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?

Two sentences with zero waste: first sentence states core purpose, second adds transparency. Information is front-loaded and well-structured.

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 2 optional parameters, complete annotations, and presence of output schema, the description sufficiently explains the tool's function and computation method. No missing critical details.

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% with clear parameter descriptions. The description adds no extra parameter info beyond what the schema provides, meeting the baseline for high coverage.

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 states 'Return LLM spend attribution (per agent/model/provider) and budget posture,' specifying the verb and resource. It distinguishes from sibling tools like cost_allocation (which allocates costs) and cost_forecast (which forecasts).

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?

No guidance on when to use this tool vs alternatives such as cost_allocation or cost_forecast. The description lacks explicit when/when-not scenarios or comparison to 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?

The description directly contradicts the annotations: it states 'Idempotent per finding' while the idempotentHint is false. This is a serious inconsistency, making the description untrustworthy about behavioral traits. Even though it discloses auth source and required scope, the contradiction nullifies transparency.

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 concise sentences: the first states the purpose, the second explains the connection mechanism, required scope, and idempotency. No fluff, front-loaded, every sentence 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?

With 10 parameters and an output schema, the description gives helpful context about the stored connection, admin scope, and idempotency claim. However, the idempotency contradiction undermines reliability, and it does not describe side effects beyond the annotation's destructiveHint. Adequate but with clear gaps.

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 schema has 100% coverage of parameters with descriptions. The tool description adds no significant parameter semantics beyond what the schema already provides; mentions of connection and idempotency are already covered in parameter descriptions (connection_id, finding_id). Baseline of 3 is appropriate.

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 states the action: 'File an ITSM ticket for a finding through a stored connection.' It uses specific verb 'file' and distinguishes this creation tool from siblings like sync_ticket_status, which suggests an update operation. The title and description align.

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 clear context by noting the tool requires an admin operator and the 'ticketing:write' scope, and that auth/base URL come from the stored connection. It does not explicitly name alternatives or give when-not guidance, but the purpose of creating a ticket is clearly implied.

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 (readOnlyHint, idempotentHint) already indicate safe read behavior. The description adds important context: it never returns secret values, and it specifically handles control-plane secrets. This goes beyond annotations by clarifying what is NOT exposed.

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: first states the primary purpose concisely, second adds detail without redundancy. Every sentence adds value, and the description is well front-loaded.

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 having no parameters and an output schema, the description fully explains the tool's purpose, scope (control-plane secrets), and what it does not return. It is complete for an agent to understand its capabilities.

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 zero parameters, the schema coverage is 100%. The description appropriately has no need to explain parameters. Baseline score of 4 for no-parameter tools is met.

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 states it returns expiring/overdue credential posture for control-plane secrets, specifying details like near expiry, overdue for rotation, and an overall verdict. This distinctively differentiates it from sibling tools which cover other security and compliance functions.

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 when credential expiry status is needed, but lacks explicit guidance on when to use this tool over alternatives (e.g., access_review, audit_query). No exclusions or context about when not to use it are provided.

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 indicate read-only, idempotent, non-destructive behavior. The description adds specific context about what is scanned (dataset_info.json, README.md frontmatter, .dvc files) and the optional PII scanning. No contradictions.

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 a single, front-loaded sentence that efficiently conveys the tool's core functionality. Every word adds value with no 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?

Given the simple tool with 2 parameters, full schema coverage, and an existing output schema, the description sufficiently covers all necessary aspects: purpose, what is scanned, and optional behavior. It is complete for an agent to use.

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%, and the description repeats the exact parameter descriptions from the schema. It adds no new meaning beyond what the schema already provides, so a baseline score of 3 applies.

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 states the tool scans a directory for ML dataset card metadata, provenance, and optionally PII/PHI content. It distinguishes from sibling scanning tools by focusing on dataset cards and adding PII scanning, making its purpose specific and unambiguous.

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 for dataset directories but provides no explicit guidance on when to use this tool versus alternatives like code_scan or model_file_scan. It does not state when not to use it or compare with 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?

The description explicitly confirms the destructive write behavior, stating it persists the fresh scan and may prune older reports, going beyond the annotations. This adds valuable context about side effects.

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 a clear first sentence stating purpose, followed by behavioral details and return value summary. Every sentence adds value, and the structure is front-loaded.

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 tool's complexity (diff with side effects) and the presence of an output schema, the description covers purpose, behavior, side effects, and return type adequately. No missing critical information.

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 schema describes the 'baseline' parameter, and the description clarifies its role and default behavior (if omitted, uses latest saved report). Schema coverage is 100%, so the description adds complementary context without redundancy.

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 states the tool compares a fresh scan against a baseline to find new and resolved vulnerabilities. It distinguishes itself from sibling tools like 'scan' by specifying the diff behavior and the fact it runs a new scan and diffs.

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 context (comparing scans to find changes), but does not explicitly state when to use this tool over alternatives like 'scan' or when not to use it. It lacks explicit 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?

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds context about default behavior (open incidents only) and incident contents (blueprint, drift score, top violations), which aids understanding without contradicting 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?

Two sentences, no filler. First sentence immediately states the action and resource. Every word serves a purpose.

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 list tool with two optional parameters and an output schema, the description fully covers purpose and incident structure. No missing essential 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?

Schema covers both parameters with full descriptions. The tool description aligns with the include_resolved default but adds no new meaning beyond the schema. Baseline 3 is appropriate given 100% schema coverage.

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 states it lists open blueprint-drift incidents and explains what a drift incident is. The verb 'list' and resource 'blueprint-drift incidents' are specific and distinct from 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 implies usage for operators reconciling drift but does not explicitly state when to use this tool over alternatives like runtime_blueprint_drift. No exclusions or when-not guidance is provided.

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 convey readOnly, idempotent, and openWorld hints. The description adds context about the output being ranked and identical to dashboard objects, but does not disclose potential limits, error handling, or performance traits. It complements annotations without 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?

The description is two sentences that deliver the core purpose and context without waste. The main action is front-loaded in the first sentence, and the second sentence adds relevant user audience information. Every word 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?

Given the tool's complexity (4 parameters, rich annotations, and an output schema), the description provides sufficient context about the intended users and use case. The presence of an output schema covers return values, and annotations cover safety, making the description complete.

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 all four parameters are already well-documented in the schema. The description does not add any additional meaning or constraints beyond what the schema provides, meeting the baseline for this dimension.

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 states the tool returns ranked ExposurePath JSON for headless security agents. It mentions specific MCP clients and distinguishes itself as the 'agent-native graph surface', differentiating from siblings like blast_radius or context_graph. However, it could more explicitly contrast with similar graph 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 indicates the tool is for headless agents and lists target clients, but it does not provide explicit guidance on when to use this tool versus alternatives like blast_radius or graph_export. No when-not-to-use or alternative references are given, only implicit context.

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 indicate destructive and non-read-only behavior, so the description's 'Writes the same entry as REST POST endpoint' aligns with that. It adds extra transparency by specifying the admin operator requirement, scope, and the justification rule for not_affected, which go beyond 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 concise—three sentences that front-load the purpose, then provide a REST equivalence and requirements. Every sentence adds value without 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?

With an output schema present, return values don't need explanation. The description covers prerequisites, scoping, and a critical parameter constraint. For a write operation with many parameters, this is adequately complete, though it could elaborate on side effects or idempotency, but annotations partly cover behavioral aspects.

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 schema has full coverage of all 13 parameters, so the baseline is 3. The description adds meaningful context by clarifying that the entry is tenant-scoped (relevant to tenant_id) and explicitly states the justification requirement for not_affected, tying to a parameter. This goes slightly above 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 clearly states the action: 'Record a tenant-scoped finding triage decision to the exception store.' This specifies a verb and resource, and the mention of the REST endpoint differentiates it from potential siblings. It is unambiguous about what the tool does.

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 usage context by stating the necessary admin operator and findings:write scope, and mandates a justification for not_affected decisions. It does not explicitly name alternative tools, but the prerequisites are clear enough for an agent to know when to use it.

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?

'Without recording it to the control-plane tally' adds explicit behavioral context beyond the annotations (readOnlyHint, idempotentHint). Consistent with annotations and clarifies the dry-run nature.

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?

Single sentence that is front-loaded with the core action and conditions. No wasted words.

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 simple dry-run nature and presence of output schema, the description does not need to detail return values. However, it lacks context on what determines the firewall decision or how results are presented, leaving some gaps.

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% and each parameter has a clear description. The tool description does not add additional parameter meaning, so baseline 3 is appropriate.

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?

'Dry-run an inter-agent firewall decision' clearly states the verb (dry-run), resource (firewall decision), and scope (inter-agent). It distinguishes from siblings that may actually enforce or record decisions.

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?

No explicit guidance on when to use this tool versus alternatives like policy_check or check. The description implies a testing use case but does not state when not to use it or which sibling to prefer.

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 indicate read-only, non-destructive, and idempotent behavior. The description adds valuable behavioral context: it explains that risk levels are category-derived (not made-up), that every field is traceable to a source, and describes the return structure. 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 concise and well-structured: a succinct first sentence, followed by bullet points explaining design context, then a clear outline of return fields, and finally an explanation of risk derivation. Every sentence serves a purpose without 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?

Given the tool's simplicity (1 parameter, no nested objects, output schema exists), the description is highly complete. It covers purpose, usage context, input format, return structure, and risk level derivation. The only minor omission is error handling, but the output schema likely addresses that.

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 schema has only one parameter ('servers') with 100% coverage. The description adds value by providing examples of valid inputs (e.g., '@modelcontextprotocol/server-filesystem, brave-search') and clarifying that it expects server names without versions. This helps the agent understand the parameter's format and use case.

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 states the tool's purpose: batch-scanning MCP server names against a security metadata registry. It specifies the target (server names), the source (registry), and the action (batch-scan). It also distinguishes itself from siblings by emphasizing its design for fleet inventory data with no version info, differentiating it from other scan 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 explicitly states when to use the tool: 'Designed for fleet inventory data (EDR, SIEM, CSV exports) where you have server names but not versions.' This provides clear context for usage. It does not explicitly exclude other scenarios or name alternatives, but the guidance is sufficiently informative for an agent to decide.

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 useful behavioral context by naming the specific outputs (durable activity, self-posture evidence) which are not in the annotations. It does not contradict annotations and provides a modest amount of additional behavioral detail.

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 a single sentence with zero wasted words. It front-loads the main outputs in a structured list and avoids redundancy with the schema. It is appropriately sized for the tool's breadth, covering all major categories without elaboration.

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 tool has moderate complexity (5 params, output schema, annotations). The description covers the main outputs but does not explain what 'durable activity' means or how to paginate via cursors, and it omits any note about when to use it relatively to sibling tools. Given the output schema and annotations, many details are covered externally, but the description is not fully self-sufficient for an agent deciding when to invoke it.

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 fully documents all five parameters. The description does not add semantic detail beyond the schema, except a slight hint that 'optional self-posture evidence' maps to include_self_posture. Per the calibration, a baseline of 3 is appropriate when the schema carries the parameter burden.

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 ('Return') and a clear resource (gateway) with its main output categories (policy, firewall, durable activity, optional self-posture evidence). It is not a tautology and distinguishes the general domain from other tools, though it does not explicitly contrast with sibling status tools like shield_status or proxy_status.

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 no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or context such as 'use for gateway health checks'. With many sibling status tools present, the lack of differentiation leaves the agent to infer usage from the name and description alone.

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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that the tool discovers agents and servers, extracts dependencies, and generates a standards-compliant SBOM, which is consistent with read-only 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?

The description is concise, front-loaded with the purpose, and uses a clear structure with bullet points for arguments and return. Every sentence contributes meaning.

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 presence of an output schema (mentioned in signals) and two optional parameters, the description provides complete context: what the tool does, how parameters work, and the return format. No gaps.

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% for both parameters. The description adds value by specifying the exact format values ('cyclonedx' and 'spdx') and clarifying config_path auto-discovery behavior, which goes 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 clearly states the tool generates a Software Bill of Materials (SBOM) for AI agent setups, with specific details on discovering agents, MCP servers, and extracting dependencies. It distinguishes itself from sibling tools like 'scan' or 'inventory' by focusing on SBOM generation.

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 states when to use the tool (to generate an SBOM) and explains config_path auto-discovery. However, it does not mention when not to use it or compare to alternatives among 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safety. The description adds behavioral detail (e.g., probing DCGM endpoints on port 9400 for unauthenticated metrics leak detection), providing context beyond annotations. No contradictions.

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?

Single sentence that succinctly captures the tool's purpose and scope with no wasted words. Front-loaded with the key verb and resource types.

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 presence of annotations (readOnly, idempotent, openWorld), an output schema (not shown but noted), and 100% parameter coverage in schema, the description adequately completes the picture. It identifies what the tool discovers without needing to explain return values.

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 both parameters already well-described in the input schema (k8s_context for K8s context, probe_dcgm for DCGM probing). The description adds little beyond framing the overall purpose.

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 uses the verb 'Discover' with specific resource types: containers, K8s nodes, and DCGM endpoints. It clearly differentiates from siblings like ai_inventory_scan or scan by focusing on GPU/AI compute infrastructure.

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 use for GPU infrastructure discovery but provides no explicit when-to-use or when-not-to-use guidance, nor does it compare to sibling tools.

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=false, idempotentHint=true, and destructiveHint=false, so the operation's safety profile is covered by structured data. The description adds modest context beyond annotations — 'one... snapshot' signals a single point-in-time artifact and 'bounded' signals constrained scope — but it does not disclose audit expectations, stale-evidence handling, or how the resulting snapshot is later retrieved.

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?

At six words, the description is extremely efficient. 'Create' is front-loaded, and every modifier — 'one,' 'bounded,' 'provenance-rich' — earns its place given that the schema and annotations carry the detailed documentation burden.

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 schema fully documents all 9 parameters, annotations cover idempotency and non-destructiveness, and an output schema exists, so an agent can technically invoke the tool correctly. However, for a tool with 9 parameters and 80+ siblings, the absence of any guidance on when to use this snapshot tool versus runtime_correlate, or how results are later consumed via graph_correlation_status, is a real gap.

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 every parameter is already documented in the input schema, which sets the baseline at 3. The description's 'bounded' and 'provenance-rich' add interpretive color about the overall operation but no parameter-level detail beyond what the schema 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 states the specific verb 'Create' and the resource 'correlation snapshot,' with 'bounded' and 'provenance-rich' conveying scope and data focus. It is clear but does not explicitly differentiate itself from closely related siblings such as runtime_correlate or graph_correlation_status, so the agent must inspect the schema to understand the distinction.

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 one-line description provides no when-to-use context, no exclusions, and no mention of alternatives. Given the sibling list contains runtime_correlate and graph_correlation_status, an agent receives no guidance on when a bounded snapshot correlation is the right choice versus runtime or status-checking operations.

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 fully covered. The description adds modest context by specifying the read facets (state, receipts, freshness, conflicts, bounds), but it does not disclose additional behavioral traits such as authorization requirements, rate limits, or what happens if the correlation no longer exists. This is consistent with annotations, adding some but not rich value.

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?

A single sentence, front-loaded with the action verb 'Read', and no filler. Each listed facet adds meaning, and the tool relies on structured schema fields for the remaining details. Efficient and appropriately compact.

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 simple read-only status tool with 2 parameters (1 required), complete schema coverage, full annotations, and an output schema, the description adequately states what it reads. It would be slightly more complete if it explicitly indicated the prerequisite correlation workflow, but the parameter description already tells the agent that correlation_id is returned by graph_correlate, filling that gap.

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 both tenant_id and correlation_id already documented. The description contributes no parameter-level information beyond the schema; the key provenance fact that correlation_id comes from graph_correlate is already in the schema. Per baseline, 3 is appropriate.

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 uses a specific verb ('Read') and enumerates the resource facets: run state, receipts, freshness, conflicts, and analysis bounds. This clearly identifies it as a status/read tool for correlation graphs, and the read verb distinguishes it implicitly from siblings like graph_correlate. However, it does not explicitly contrast with any sibling, so it falls just short of the top score.

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 no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of the expected workflow (e.g., after graph_correlate). The schema parameter description for correlation_id does imply the correlation flow, but the tool description itself offers no usage direction.

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 read-only, non-destructive, idempotent, and open-world behavior. The description adds value by specifying that the tool returns the graph as a string in the requested format, which is not disclosed 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 very concise: a single sentence for purpose, bullet points for formats, and a returns line. It is front-loaded with the main action, and every sentence provides necessary information without 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?

Given the tool's simplicity and the presence of a full schema and annotations, the description covers the essential aspects: purpose, formats, and return type. It is complete enough for the agent to understand and use the tool, though it omits error handling or edge cases (e.g., what happens with invalid format).

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 lists the format options but does not add meaning beyond the schema's description of each parameter (e.g., config_path, format, mermaid_limit). The description does not compensate for any missing schema details.

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 states the tool exports the agent dependency graph in specific graph-native formats (graphml, cypher, dot, mermaid, json). The verb 'export' and resource are well-defined, and the listing of formats distinguishes it from other tools like context_graph or scan 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 implies use when a graph-native format is needed, but it does not explicitly state when to use this tool versus alternatives (e.g., context_graph for other representations) or when not to use it. No exclusions or preconditions are provided.

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 context beyond annotations: it confirms the destructive nature (already hinted by destructiveHint=true) and specifies required roles/scopes and audit requirements. No contradiction 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 concise (two sentences), front-loads the purpose, and adds prerequisites efficiently. No unnecessary words.

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 tool has 8 parameters, destructive annotations, and an output schema, the description covers the core purpose and key requirements. It could mention the temporal nature or return values, but the output schema likely covers that.

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. The description does not add extra explanation beyond the schema, but it is not expected to since the schema already explains each parameter adequately.

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 states the verb 'Grant' and the resource 'identity time-bound JIT access to one tool', which is specific and distinguishes from sibling tools like identity_revoke (revoke access) and identity_rotate (rotate credentials).

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 lists prerequisites (admin role, identity:write scope, audit reason), which guides usage. It implies when to use (for temporary access) but does not explicitly state when not to use or compare to 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?

Description discloses that the tool returns a raw token once, adds requirement context beyond annotations (which show destructive=true), and notes non-idempotent and destructive nature.

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 covering action, prerequisites, and return value; no extraneous content.

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 9 parameters and an output schema, description covers prerequisites and output type. Could mention default behaviors but overall adequate.

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 description adds minimal extra meaning beyond schema. Baseline score is appropriate.

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 action 'Issue a managed agent identity' with specific verb and resource, and distinguishes from sibling tools like identity_revoke and identity_rotate.

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 lists prerequisites (admin role, identity:write scope, audit reason) but does not explicitly state when to use this tool over alternatives like identity_grant_jit.

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 confirms the destructive nature ('immediately') and adds behavioral context about required authentication and audit logging, beyond what annotations (destructiveHint=true) alone provide.

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?

Single sentence front-loads the action and immediately follows with critical usage requirements. No wasted words.

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 annotations, output schema existence, and complete parameter descriptions, the description covers the key aspects. Lacks details on post-revocation state but is adequate for a destructive action.

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%. The description references the purpose of parameters (e.g., 'audit reason') but adds no new semantic detail beyond the 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 uses the specific verb 'Revoke' and resource 'managed identity', clearly distinguishing it from sibling tools like identity_grant_jit or identity_rotate.

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 states explicit requirements (admin role, identity:write scope, audit reason), providing clear usage context. However, it does not mention when not to use or alternative tools.

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 indicate destructiveHint=true, so the description's mention of 'Revoke' aligns. It adds value by specifying authorization requirements (admin role, scope) and the need for an audit reason, which are not covered by 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 two sentences, efficient and front-loaded with the action and requirements. No unnecessary words 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?

Given the 100% schema coverage and existence of an output schema, the description is adequate. It covers the tool's purpose, prerequisites, and required parameters, enabling an agent to use it 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 the schema already documents each parameter. The description adds minimal extra value beyond what the schema provides, justifying a baseline score of 3.

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 the verb 'Revoke' and the resource 'active JIT grant', and specifies immediate action. It clearly differentiates from sibling tools like identity_grant_jit (grant) and identity_revoke (generic revoke) by focusing on JIT grants.

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 mentions required admin role, identity:write scope, and audit reason, providing clear context for when to use the tool. However, it does not explicitly contrast with alternatives like the generic identity_revoke, but the sibling list helps differentiate.

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 behavioral context beyond annotations: it notes that the old token stays live during the overlap window, which is critical behavior not captured by the destructiveHint annotation. Requirements are also included.

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 concise sentences: first explains the core action and key behavior, second lists requirements. No unnecessary words.

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 high schema coverage and presence of an output schema, the description covers the essential action and requirements. It lacks explicit guidance on when to prefer this over siblings, but the sibling list provides 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?

Schema description coverage is 100%, so the description adds no new parameter information beyond referencing the overlap window, which is already described in the schema. Baseline 3 applies.

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 states the verb 'rotate' and the resource 'managed identity' with a specific behavioral detail about keeping the old token live. This distinguishes it from sibling tools like identity_grant_jit or identity_revoke.

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 lists prerequisites: admin role, identity:write scope, and audit reason. It does not explicitly state when not to use, but the clear prerequisites and context provide sufficient 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?

Beyond the destructiveHint annotation, it explicitly states the mutation side effects, including bulk-ingesting findings and resolving open findings absent from the batch, and notes the required scope. It also clarifies that parse_only keeps it a read. This is rich behavioral context.

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 clear one-sentence summary, followed by a focused paragraph on behavior. Every sentence conveys necessary information without waste.

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 description need not explain return values. It covers core aspects: accepted formats, non-execution, write gating, authentication scope, and the read-only parse_only path. This is sufficient for an agent to decide and invoke 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 the schema already documents parameters. The description adds meaning by explaining the behavior implied by parse_only (read vs. write) and reconcile_absent (resolving absent findings), which goes beyond the schema 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 a specific verb ('Ingest') and resource ('external SARIF, SBOM, or scanner JSON'), and the phrase 'without executing its producer' distinguishes it from scanning tools. This clearly differentiates it from siblings like 'scan' and 'generate_sbom'.

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 explains the conditional write behavior ('mutates the control plane when parse_only is false') and notes the destructive-action gating with findings:write scope. However, it does not explicitly name alternative tools or provide direct 'use when vs. instead of' guidance, 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds minimal behavioral context beyond stating it is from governed sources. It does not disclose potential limitations, data freshness, or failure states, but annotations cover the safety profile adequately.

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 a single, front-loaded sentence that conveys the core purpose efficiently. Every word is meaningful, and there is no redundancy or unnecessary elaboration.

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 tool has 8 optional parameters and an output schema, the description is adequate but does not elaborate on what 'local' means or the nature of 'governed intel sources.' It relies on the schema and output schema for full context. For a daily brief tool, additional context on scope or typical usage would improve completeness.

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 does not add any additional semantic meaning for the parameters beyond what the schema provides. The parameters are well-documented in the schema, so the description's lack of param details does not detract.

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 states the tool returns a local analyst threat brief from governed intel sources. It specifies a specific verb ('Return'), resource ('threat brief'), and source ('governed intel sources'), distinguishing it from siblings like intel_lookup (specific indicator lookup) or intel_sources (source listing).

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 for obtaining a daily brief but provides no explicit guidelines on when to use this tool versus alternatives like intel_lookup or audit_query. No exclusions or conditions are mentioned, leaving the agent to infer context.

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, destructiveHint=false, idempotentHint=true. Description adds 'local threat-intel database' context, indicating no external fetch. No contradiction. However, it doesn't detail behavior on missing IDs or performance considerations.

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?

Single, well-structured sentence that is front-loaded and free of redundancy. Every word 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?

Given simplicity (1 param, output schema exists, annotations rich), the description is nearly complete. Minor gap: no mention of error handling or edge cases like invalid IDs, but output schema likely covers return structure.

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%, and the schema's parameter description already provides detailed format guidance (e.g., 'CVE-2024-1234 or GHSA-abcd-1234-wxyz'). The tool description adds no new parameter-level information beyond 'one advisory,' so baseline 3 is appropriate.

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 'Look up one advisory from the local threat-intel database.' It specifies a specific verb (look up) and resource (advisory from a local database), distinguishing it from siblings like intel_match which likely handle multiple matches.

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 when a specific advisory ID is known, but lacks explicit guidance on when to use this tool versus alternatives like intel_match or intel_sources. No mention of when not to use or prerequisites.

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 readOnly, idempotent, non-destructive, open world. Description adds that matching is against 'local' advisories, providing context beyond annotations without 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?

Single sentence, no fluff, front-loaded verb. Efficient and clear for a tool with high schema coverage.

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 full schema, annotations, and output schema, the description is sufficient. Could hint at batch matching (packages parameter) but schema already does. Not a gap.

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 has 100% coverage with detailed descriptions for all 6 parameters. Description only vaguely mentions 'package inventory coordinates' but adds no new semantic value beyond 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?

Description uses specific verb 'match' and resource 'package inventory coordinates' to threat-intel advisories. Clearly distinguishes from siblings like intel_lookup and intel_daily_brief.

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?

No explicit when-to-use or when-not-to-use guidance. Does not mention alternatives like intel_lookup or scan. Usage is implied but not clarified.

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 and idempotentHint, so the description needn't restate. It adds value by specifying the kind of data returned (canonical sources, freshness), which is transparent beyond 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?

A single, information-dense sentence that front-loads the purpose with zero fluff.

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 zero-parameter tool with an output schema, the description completely covers the purpose and return value, leaving no ambiguity.

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?

No parameters exist, so the description has no burden. Baseline 4 is appropriate as the tool is trivially parameter-free.

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 uses a specific verb ('Return') and names the resource ('canonical threat-intel sources', 'local feed-run freshness'), clearly distinguishing it from siblings like intel_lookup and intel_match.

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 (getting a catalog), but lacks explicit when-to-use or when-not-to-use guidance relative to alternative tools among the 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?

Annotations already convey safety and idempotency; description adds the 'no CVE scanning' trait but omits other behaviors like output details.

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?

Single efficient sentence front-loaded with action verb, no unnecessary words.

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 rich annotations, schema, and output schema, the description is largely complete, adding the key differentiator; could mention output scope but not required.

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 covers the parameter fully; tool description adds no extra meaning beyond 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?