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

Beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=false), the description discloses the exact financial consequence ('settlement spends USDC irreversibly'), absence of refunds, the non-idempotency nuance (same args alone are not enough; need idempotency-key metadata and original payment proof), and the epistemic limit ('Does not establish absolute truth'). This aligns with and substantially extends the annotation signals.

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 description is compact and front-loaded: purpose first, then risk, then retry behavior. Every clause adds safety-critical information, though the final idempotency sentence is dense and could be structured a bit more clearly.

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?

With an output schema and annotations, the description handles the high-level purpose, safety, and retry behavior well. It falls short on completeness because the parameter semantics are almost entirely absent, and 'price and payment requirements' are referenced without pointing to a concrete source (e.g., vigil_pricing) or explaining how max_price_usd/max_age_seconds affect the call.

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%, and the description provides almost no mapping to the three parameters: it never explains `source_url`, `claim`, or the `options` object (max_price_usd, max_age_seconds). The only indirect link is 'price and payment requirements' hinting at cost, but that is insufficient to compensate for undocumented parameters.

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?

The description opens with 'Paid source-local verification with exact evidence and signed receipt', which names a concrete action (verify a source), a distinguishing paid/source-local scope, and a deliverable (signed receipt). It does not fully unpack what 'source-local' means or compare against verify_receipt/verify_lease, but it is far from tautological.

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 text implies usage context with 'source-local' and 'Does not establish absolute truth', and it gives a clear precondition ('Read price and payment requirements before authorizing') plus retry guidance. However, it never states when to choose this tool over sibling verification tools or when not to use it, so selection guidance is only implicit.

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