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 safety profile is covered. The description adds real value by naming exactly what gets recomputed (hash, notary payload, invariants, pack currency), telling the agent this is a consistency check rather than a simple read. It does not say whether failures throw or are reported, but the output schema covers the return contract.

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 short sentences with no filler, and the operations performed are front-loaded before the parameter instruction. Slightly dense with undefined terms, but nothing is wasted.

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 carry the safety profile. What remains missing is the relationship to compile_disclosure (which produces the 'prior result') and any failure semantics, which matter for a verification tool.

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

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

Schema coverage is 0% and the single parameter is documented only as a string titled 'Result Json'. The description partially compensates by saying to pass the prior result as JSON, which clarifies format and provenance, but gives no indication of the expected result shape or whether it must be verbatim from a prior tool call.

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?

Specific verb ('Recompute') followed by an enumerated set of artifacts checked: audit hash, notary payload, structural invariants, framework-pack currency. This clearly separates it from compile_disclosure and get_framework. It loses a point only because the enumerated items are domain jargon an agent may not map to sibling concepts.

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?

'Pass the prior result as JSON' implies this runs as a post-hoc check on output from another tool (presumably compile_disclosure), which is an implied usage. However, it never states when to use this versus compile_disclosure or what to do when verification fails, and offers no exclusions.

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