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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses the price ($0.60), the free-refusal policy (coverage_gap with no_charge for anything unanswerable), the shared rate limit of 3 free calls per IP per day, both auth paths (api_key vs x402 402 response), and that receipts are only issued on paid successes. This is exactly the operational context 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 cost and the composite purpose are front-loaded and nearly every clause carries information (pricing, refund policy, rate limit, auth, receipt caveat). It runs long and the receipt/certified-extract distinction is repeated in both description and schema, which is slight redundancy rather than waste.

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 14-parameter paid composite tool with an output schema and full annotations, the description covers the remaining gaps: billing model, free-refusal semantics, rate limits, regional coverage, the receipt concept and how to verify it via verify_answer_receipt, and the explicit non-legal-advice / non-certified-extract disclaimers.

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?

With schema coverage at 86% the schema already does most of the work, but the description adds real meaning: the enumerated seller-country universe constrains seller_country beyond 'ISO country code', and the due_date vs invoice_date+terms_days alternation is stated as a usage rule. It also explains the api_key bypass and that receipt defaults to false with no extra USDC charge.

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 verb and resource plus the exact sub-checks performed: VAT correctness (place of supply, rate, expected vs vat_charged), overdue status and statutory late interest, and tax-ID format validation. Listing supported seller countries (BO, BZ, CL, CO, CR, EC, HN, MX, NI, PA, SV, TT, UY) further narrows what the tool is, letting an agent distinguish this composite check from siblings like compute_vat, compute_statutory_interest, and validate_tax_id.

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 explicit invocation context: use it as a one-call invoice check, supply due_date or invoice_date with terms_days, and pass api_key if available or expect the x402 payment requirement. However, it never explicitly says when NOT to use it — e.g., use compute_vat alone if only the VAT rate is wanted, or validate_tax_id for a standalone ID check — so the routing to siblings is implied rather than stated.

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