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

Annotations already cover read-only/idempotent/non-destructive safety, so the bar is lower; the description adds real value with the return structure (total rate plus per-layer breakdown: MFN, Section 301 China, Section 232, Section 301 Brazil, forced-labor tariff), the post-exclusion rate, sort order, and a concrete expiry date with a cited source and noted discrepancy. It also discloses the important limitation that estimates exclude preferential/FTA rates because rules of origin are not assumed.

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-loaded with what it does and the scope constraint, then moves to return shape and caveats; nearly every clause carries information. It is dense to the point of being a single long paragraph, and the parenthetical about the Federal Register vs USTR date discrepancy is more detail than an agent needs to select or invoke the tool.

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?

No output schema exists, so the description must explain the return value — and it does, enumerating the rate layers, the post-exclusion rate, sorting, and optional dollar duty. Combined with the estimate-only disclaimer and the code-lookup pointer, an agent has everything needed to call 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 description coverage is 100% and the schema already states the 6–10 digit HTS format, the 2–8 country limit with default set, and that annual_import_value_usd adds a duty figure. The description merely echoes these ('with the dollar duty when an annual import value is given'), adding no syntax or unit detail beyond structured data.

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 (compare) + resource (estimated US import tariff) + explicit scope constraint (ONE HTS code across several origin countries), with concrete examples (China vs Vietnam vs Mexico vs India). It is clearly distinguishable from calculate_tariff (single-origin computation) and lookup_hts_code (code resolution).

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?

Names the decision context (sourcing / 'China plus one') and the scope rule (one HTS code, multiple origins, sorted lowest first), and the schema points to lookup_hts_code when only a product name is known. It does not explicitly say when to use calculate_tariff instead, so siblings are separated by implication rather than statement.

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