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

Beyond readOnlyHint and openWorldHint=false, it spells out the side-effect boundary ('reads only the material in the call: no page fetch, no account access, no merchant contact and no money movement'), the pricing and free-call allowance, the x402 exact scheme on Base, the required X-Wever-Wallet-Proof binding to the exact JSON arguments and route, the signed Ed25519 receipt, and the interpretive limit ('does not interpret meaning beyond that matching'). That is unusually rich behavioral context that the annotations cannot convey.

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 purpose is front-loaded and the following sentences cover mechanism, then cost, then auth, then the report, then the contract links, with essentially no filler. It is a dense single block of roughly ten sentences, and the payment/auth portion is long relative to the core task, but each part carries information an agent needs.

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?

There is no output schema, yet the description states what the report contains (per-claim supported/contradicted/never-mentioned verdicts with quotes and a signed receipt), how inputs are split and compared, what the tool will not do, and how to pay and authenticate. Nothing an agent needs in order to call it correctly appears to be missing.

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 meaning beyond the schema by explaining what is actually compared: durations in any unit, clock times, regions and affected shares, and a stated duration or start/resolution time checked against the supplied timeline, with quotes. It does not add anything about the format parameter, but the substantive comparison semantics are covered.

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?

It uses a specific verb and resource: submit incident claims about duration, scope, cause and resolution, plus the timeline or postmortem evidence offered for them, and it returns a per-claim verdict of supported, contradicted or never mentioned. The incident framing narrows it against the many other *-evidence-check siblings, though no sibling is named explicitly for contrast.

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 (you have incident claims and supporting evidence, and you want them checked) and states the comparison dimensions, but it never says when to prefer this over wever_claim-evidence-check, wever_status-evidence-check or wever_sla-evidence-check, nor does it give exclusions or prerequisites beyond the wallet/payment mechanics.

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