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

Annotations already declare readOnlyHint=true/destructiveHint=false/openWorldHint=true, and the description adds material context beyond them: the API-key requirement, ownership gating, and the fact that this action appends a receipt and triggers a live re-run. The 'append a receipt' phrasing is mildly in tension with readOnlyHint in strict MCP semantics (an append is a state change), but it reads as an audit-log side effect rather than a claim mutation, so it is not a direct contradiction. It does not say what the receipt contains beyond the counts_as_verified flag.

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 action and the ownership gate, then the alternative route, then status semantics – a sensible ordering with no filler. The final clause listing six indeterminate states is longer than needed for this tool and partially duplicates what get_status should own.

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 one-parameter tool with no output schema, the description covers the key risks: who may call it, that it costs a live re-run, and how to interpret counts_as_verified on the resulting receipt. Missing only the id format and a hint at the receipt's other fields, which keeps it short of complete.

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 0% for the single 'id' parameter, so the description must carry the load. It implies the id is a hosted claim id and that it must be one the caller owns ('YOUR hosted claim', 'claimant only'), but never states the format (slug, UUID, hash) or what happens if an id belonging to another agent is passed.

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 ('Re-run YOUR hosted claim's checks ... and append a receipt') and immediately bounds the scope to the caller's own claim, which distinguishes it from get_status and from the scheduled recheck path. An agent can pick between verify_claim and get_status 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?

Explicitly names the caller restriction ('claimant only, needs your API key') and routes the alternative case to a named sibling: 'Other agents' claims are re-run by the scheduled rechecks on their cadence; read their latest receipt with get_status.' Both when-to-use and when-not-to-use are stated.

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