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

Annotations already declare readOnlyHint=false and idempotentHint=false; the description goes beyond them by disclosing concrete write side effects (immutable audit records EVL-... in SweGateStore, sealed cryptographic blocks in TraceKitStore), which tells the agent this call mutates state and is not a dry run. It does not say whether records are still appended when the verdict fails, which is the remaining unknown for a mutation tool.

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

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

Two sentences with no filler, front-loaded on the verification purpose with side effects and sibling routing deferred to the second sentence. The parenthetical parameter lists make it dense but each clause carries distinct 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?

With an output schema present, the description correctly avoids restating return values and instead covers the axes of evaluation, persistence side effects, and where to read results back. The open question of whether failed patches are still recorded in the audit ledger is the one behavior an agent would want before calling it repeatedly.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds semantic grouping the schema lacks: it clusters max_cyclomatic_delta, forbid_type_ignores and disallowed_import_modules as the architectural constraint set, and tests_passed, tests_failed, functional_verdict as the functional evidence. It stops short of explaining how diff_text is parsed or whether diff_size_bytes is derived or trusted.

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 names a specific verb and resource ('Verify a unified git diff patch') and enumerates the exact validation axes it applies (cyclomatic delta, type ignores, banned imports, functional verdict). It also clearly separates itself from siblings by assigning record retrieval to query_audit_ledger.

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 gating context is explicit ('before allowing merge'), and it routes the agent to the correct sibling for retrieval/verification of persisted records. There is no explicit when-not guidance or distinction from evaluate_spec_axioms / resolve_context_bundle, which is the only gap.

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, destructiveHint=false and openWorldHint=false, so the closing 'Pure read-only analytical evaluation with no side effects' largely restates structured data. It adds no new behavioral detail such as thresholds, failure modes, or what an ACI below 1.0000 produces, leaving it at adequate-but-thin 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?

Three tight sentences, front-loaded with the core purpose before the routing hint and the safety note. No filler or repetition; every clause carries actionable 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?

An output schema exists, so return values need not be explained, and annotations already cover the safety profile. For a single-parameter analytical tool, the description plus structured fields give an agent everything needed to invoke 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?

There is a single parameter with 100% schema description coverage, so the schema already documents `brief_text` as markdown brief content. The description names the parameter but adds no format constraints or size limits beyond the schema, matching the baseline 3 for high-coverage schemas.

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

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

States a specific verb (Evaluate) plus the exact resource (an architectural specification brief) and enumerates the rule families it checks (determinism rules, negative invariant floors, ACI 1.0000). It explicitly distinguishes itself from the sibling evaluate_patch, so an agent can route without opening any schema.

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

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

Gives both the when ('during intake or planning phases before writing code') and the alternative ('For verifying unified git diff patches, use evaluate_patch instead'). The selection condition between the two siblings is explicit and unambiguous.

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

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

Annotations already establish readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: bodies are replaced with AST stubs while docstrings can be stripped, and it is a pure in-memory operation that does not modify files on disk. It stops short of describing return/error behavior, but the output schema covers returns.

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

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

Front-loads the extraction verb and its targets, then usage routing, then the side-effect disclaimer. It is dense but each sentence earns its place; the long opening clause is somewhat loaded but remains readable and purposeful.

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 need not be explained. The description covers purpose, parameter meaning, usage routing, and the key constraint that nothing is written to disk, which is sufficient for an agent to invoke this 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 description coverage is 100%, so the schema already documents all four parameters and their defaults. The description restates depth values and the effect of strip_docs and language, adding only light semantic framing rather than new syntax or constraints beyond the schema, so 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?

States a precise verb and resource: extract semantic interfaces, types, models, raises, and signatures from a source file, with named scope controls (depth, language, strip_docs). It also names the sibling it is not (resolve_context_bundle) for multi-module graphs, so an agent can distinguish it without opening either schema.

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

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

Gives explicit when-to-use ('when you only need to inspect contracts or APIs of an individual dependency without ingesting raw implementation code') and an explicit alternative with its selecting condition ('For multi-module dependency graphs, use resolve_context_bundle instead'). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description reinforces this ('zero ledger mutations') while adding genuine context: SHA-256 hash-chain integrity verification and optional block enumeration. It does not note rate limits or failure modes for an invalid id, which keeps it short of a 5.

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

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

Purpose is front-loaded in the first clause, followed by usage and then the read-only guarantee; every sentence earns its place. The two sentences are dense with parenthetical id formats, which slightly hurts scannability but not correctness.

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, all four parameters are documented in-schema, and annotations carry the safety profile, so the description need not explain return values. It covers the dual query modes, the optional block expansion, and the forensic use case, leaving nothing essential an agent would need.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by tying parameters to modes: evaluation_id versus session_id selection, and include_blocks/max_blocks as optional block listing for the session path. That mode-to-parameter mapping is value the schema alone doesn't express.

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 names a specific verb (retrieve/verify/inspect) and two distinct resources: persisted SWE-Gate evaluation records by EVL id and hash-chained TraceKit audit sessions by SES id. It also distinguishes the two lookup modes, so an agent can tell which branch to take without opening the schema.

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

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

It states the trigger context clearly: use for forensic inspection and compliance verification after running evaluate_patch or other context tools, explicitly referencing the sibling evaluate_patch. It does not state when NOT to use it versus siblings like resolve_context_bundle, but the intended post-evaluation workflow is unambiguous.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds substantive behavior: what gets included per tier (full file vs. interface stubs vs. nominal symbols), token pruning, and reactive degradation through `breaker_state`/`session_id`. 'Read-only operation' is redundant with the annotations, and return format is left to the output schema.

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

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

Front-loaded with the core operation, then usage guidance, then the alternative. Dense but every clause carries selection value; the trailing 'Read-only operation' duplicates the annotations and is the only wasted sentence.

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 need no explanation, annotations carry the safety profile, and 100% schema coverage handles parameters. For a four-param read tool, the description covers purpose, routing, and tier semantics fully.

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 four parameters, including the D0 mapping for `target_file`. The description reinforces that mapping and frames `breaker_state`/`session_id` as reactive degradation, but adds no syntax, defaults, or formats beyond what the schema states. 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?

States a specific verb+resource: 'Calculate topological dependency graph distances ... and compile a token-pruned Markdown context bundle', with the D0/D1/D2 tier scoping spelled out. It explicitly differentiates itself from the sibling `prune_file`.

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

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

Gives an explicit when: 'primary context builder before editing a file in a multi-module project', and names the alternative with its own condition: 'For inspecting isolated files, use `prune_file` instead.' Nothing is left to inference.

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