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

The annotations already declare readOnlyHint/destructiveHint=false, so 'READ-ONLY: this call changes nothing' mostly restates structured data, though it usefully adds that the call is repeatable and requires no auth — real context beyond the annotations. What is missing is the important behavioral question for a verifier: what happens on a hash mismatch (error, boolean, diff payload) and whether it verifies from genesis or from the given starting points.

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 short sentences with the core action front-loaded and the auth/read-only caveats after it. Minor waste in re-asserting read-only properties already carried by annotations.

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 tool with zero required parameters and no output schema, the description should say what the default verification covers and what a result looks like — success/failure shape, mismatch reporting, and the meaning of the ledger vs identity chains. None of that is present, leaving the agent unable to predict the response.

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 60%: 'from', 'ledger_expect', and 'identity_expect' are documented, but 'ledger_from' and 'identity_from' have no descriptions in either schema or description. The phrase 'saved row/hash witnesses' gestures at the starting-point parameters but never explains how ledger_from/identity_from select the segment being verified, so it does not compensate for the gap.

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 (verify) and specific resources (identity and treasury linear hash chains), which distinguishes it from generic siblings like attestation or inclusion_proof. It does not name a sibling it replaces or explain the difference from checkpoint_consistency, so it stops short of a 5.

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

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

'optionally from saved row/hash witnesses' hints at a usage mode, and 'No auth needed' removes a common blocker, but it never says when to choose this over attestations, witnesses, witness_history, or checkpoint_consistency. The agent must infer the selection criteria from the tool name alone.

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