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

With no annotations available, the description carries the full disclosure burden and meets it: it declares the $0.02 cost, the x402 payment fallback, receipt conditions, the non-certified/non-legal status of the receipt, and the verification route. This goes well beyond what the schema alone reveals.

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 front-loaded with cost and purpose and contains no filler. However, the receipt/certified-extract caveat largely repeats the input schema's receipt description, and the unsupported Ghana example adds noise, so it is not maximally economical.

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?

There is no output schema, so the description must convey return semantics, and it does: net/tax/gross plus per-levy components for composite rates. Payment, auth, receipt, verification, and limitations are all covered, leaving no obvious gap for an agent to call the tool 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% and the schema already documents mode and receipt semantics, so the baseline is 3. The description adds useful api_key/payment behavior and output composition context, but its Ghana example is not in the country enum (au/fj/nz/pg/sb/to/vu/ws), which could mislead an agent choosing a country; this prevents a higher score.

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 a concrete action and resource: it produces a VAT breakdown (net, tax, gross) at the country's statutory rate and explains mode behavior. This clearly separates it from siblings like compute_income_tax and compute_employment_cost. The composite-rate mention adds useful product specificity.

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 mode-selection rules (add vs extract), explains the payment and api_key flow, and warns that an answer receipt is not a certified extract nor legal advice. It also routes verification to verify_answer_receipt, making the when-to-use and when-not-to-use guidance concrete.

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