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

Goes well beyond the annotations: confirms the tool reads only the supplied material with no page fetch, registry lookup, counterparty contact, or payment movement; discloses the paid path (0.10 USDC per call on Base via x402, 10 signed-wallet free calls per rolling 30 days) and the X-Wever-Wallet-Proof binding to the exact JSON arguments and route; and states the result carries an Ed25519 signed receipt.

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 opening clause front-loads the purpose and the safety statement is explicit, with no filler sentences. The middle is a single very long run-on listing report contents and constraints, which costs some readability, but every element carries 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?

For a no-output-schema tool with nested fields, the description explains what the report contains (per-area marks, quotes, ready/partial/missing status, weakest links first), plus cost, auth header binding, and the contract/human URLs. An agent has what it needs to call it and interpret 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 100%, so the schema already documents every field and the the text/fields precedence rule. The description only restates the input shape ('text, fields ... or both') and adds no format, size, or enum guidance beyond what is structured. 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 and resource ('check recovery arrangements') and enumerates the exact areas assessed: backups and recency, key recovery method, export paths, restore steps, and restore-test evidence. It is clearly a recovery-readiness audit distinct from adjacent preflight checks, though it never names a sibling alternative to route against.

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 a clear usage condition: run it 'before you depend on' the recovery arrangements, framed as 'Agent preflight round 2'. It supplies no exclusions and does not point to related checks (e.g. continuity or handover checks) that an agent might confuse it with.

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