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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive) the description discloses pricing ($0.25), the two payment paths (api_key vs x402), the shared 3-calls-per-IP-per-day quota, the exact refusal behavior (coverage_gap, no_charge), and receipt semantics with a verification pointer. These are material operational traits an agent cannot get from 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?

Long but justified by genuine payment and receipt complexity; the paid price and core purpose are front-loaded. Some redundancy exists, since the receipt semantics are restated in both the description and the schema entry, but every clause otherwise 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?

With an output schema present, return values need not be re-explained. For a paid, rate-limited, refund-capable tool the description covers cost, payment flow, refusal handling, quota sharing, receipts, and verification, which is complete enough for an agent to invoke it correctly.

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 parameters are already documented, establishing a baseline of 3. The description goes beyond it by explaining the series default ('first certifiable of vat, policy-rate, minimum-wage'), the all-must-be-certifiable constraint, and the receipt's paid-success-only condition, adding genuine meaning to two of the four 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 states a specific resource and composition: a country evidence pack bundling the full cited country brief plus up to 3 Ed25519-signed certified extracts. It is far more specific than a tautology and names the constituent parts. It stops short of explicitly contrasting with the sibling get_country_brief or the standalone certified-extract SKU, so sibling differentiation is only implicit.

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?

It gives real use-time context: series must all be certifiable, anything unanswerable is refused free, api_key should be passed if held, otherwise expect the x402 payment requirement. It also distinguishes the answer receipt from the $0.10 certified extract endpoint. It does not explicitly say when to prefer this pack over get_country_brief or the compute_* / check_* siblings, so the alternative-selection rule is left to inference.

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