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

Goes well beyond the readOnly/idempotent annotations: discloses price ($0.60), the free-refusal policy on coverage_gap with no_charge, a shared rate limit of 3 free calls per IP per day across answer tools, the x402-vs-api_key payment path, and receipt behavior on paid success only. It also explicitly disclaims that an answer receipt is not a certified extract nor legal advice.

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-loads price and purpose, then constraints, then payment and receipt mechanics — a sensible order with little filler. It is dense with parentheticals and the receipt/payment sentences are long, which costs some readability but not correctness.

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 tool it covers what the agent most needs: what is checked, supported countries, date input rules, refusal and pricing behavior, and payment modes; the output schema handles return shape. Buyer-side country coverage and the meaning of a partial/coverage-gap result are left implicit.

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 86%, so the schema carries most parameter meaning. The description adds genuine value beyond it by constraining seller_country to five supported jurisdictions and clarifying the due_date vs invoice_date+terms_days relationship, but it says nothing about amount_is, buyer_type, or as_of semantics.

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 and resource (check an invoice) and enumerates the three exact outputs: VAT correctness against vat_charged, overdue status plus statutory late interest, and seller/buyer tax ID format validation. This makes clear it is a composite one-call check rather than a single-purpose sibling like compute_vat or 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?

Gives concrete invocation guidance: 'Send due_date, or invoice_date with terms_days', and lists the supported seller countries (FJ, NZ, SB, TO, WS), which tells the agent when the tool is inapplicable. It implies but never explicitly names the alternative single-purpose siblings for the cases it cannot cover, so a 4 rather than 5.

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