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

Despite annotations already declaring readOnly/idempotent/non-destructive, the description layers on pricing ($0.25), the free-refusal path (coverage_gap, no_charge), shared rate limits, payment mechanics (x402 vs api_key), and receipt conditions on success vs 402 vs refusal. This is unusually rich behavioral disclosure beyond the structured fields.

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 price and content, and most sentences carry distinct facts (refusal policy, rate limits, payment, receipt). It is dense and slightly repetitive, since the receipt param schema restates much of the same receipt/legal-advice caveat, but little is pure filler.

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?

An output schema exists, so return-shape explanation is unnecessary, and the annotations cover safety. Given a 4-param, payment-gated tool, the description supplies everything an agent needs: cost, refusal semantics, auth options, rate limits, and verification pointer to verify_answer_receipt.

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 already 100%, so the baseline is 3, but the description adds genuine meaning: series defaults to the first certifiable of vat/policy-rate/minimum-wage and all named series must be certifiable, and receipt is scoped to paid successes only and explicitly distinguished from a certified extract. It adds value beyond the schema text.

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 paid resource ('Country evidence pack') with its exact composition: the full cited country brief plus up to 3 Ed25519-signed certified extracts. It distinguishes itself from siblings by noting that the certified-extract endpoint 'is not an MCP tool' and by clarifying the relationship to the answer tools.

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 clear operational context: series must all be certifiable, unanswerable requests are refused free with coverage_gap, the 3 free calls/day are shared with the answer tools, and api_key vs x402 payment routing is explained. It stops short of explicitly comparing against the closest free sibling (get_country_brief) to say when this paid pack is preferred over it.

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