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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable behavioral context: it explicitly states this is a 'Premium API' with a cost of $0.35 USDC via x402, which is not in the annotations. It also enumerates the types of data returned (MFN rates, FTA rates, VAT/GST, etc.), giving the agent a clear expectation of the response contents without needing an output schema.

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 a single, information-dense sentence that leads with the core action ('Retrieve import customs duty rates') and then lists the specific rate types and the cost. It is concise and front-loaded, with no filler words or redundant phrases. It could be slightly shorter by omitting the exhaustive list, but that list adds value by setting expectations for the response.

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 read-only rate retrieval tool with full parameter documentation and safety annotations, the description is nearly complete. It covers the purpose, the type of data returned, and the cost. There is no output schema, but the description compensates by listing the expected data categories. It doesn't mention rate limits or authentication, but the annotations cover idempotency and safety, and the cost mention implies payment requirements. Overall, it gives the agent enough 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 description coverage is 100%: both 'hscode' and 'lookup' have clear descriptions with examples (e.g., '8471.30' and 'Germany'). The description adds minimal new parameter semantics—it repeats that any HS code and any country are accepted, which is already implied by the schema. Since the schema fully documents the parameters, a baseline score of 3 is appropriate.

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 clearly states the verb 'Retrieve' and the specific resource: import customs duty rates for any HS code entering any country. It lists the specific types of rates and duties included (MFN, preferential FTA, VAT/GST, additional duties, de minimis, non-tariff restrictions), which fully distinguishes it from sibling tools like currency_rate, eu_vat_rates, and sales_use_tax_rates. The name and description together leave no ambiguity about what this tool does.

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?

The description implicitly indicates when to use this tool—whenever customs duty rates are needed for a given HS code and destination country. It does not explicitly name alternatives or state when not to use it, but given the unique subject matter among the siblings, an agent can easily infer its use case. The cost mention (Premium API) also suggests it may be used selectively, though it doesn't contrast with cheaper alternatives.

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