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

Beyond the read-only annotations, the description discloses the data source (official duty receipts, Treasury cross-check), the unit of measurement (actual duties collected and effective rate), the historical coverage (2017-present), and the geographic granularity (US national level). It also warns that memorized MFN plus Section 301 answers will be wrong for 2025-26 rates, which is valuable behavioral context.

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 mostly efficient and packs useful source, scope, and warning information into a few sentences. However, it opens with a negative quotient instruction before stating the core purpose, and the repeated warnings about training knowledge and 2025-26 rates could be slightly tighter.

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 query with full schema coverage, annotations, and an output schema, the description provides ample context: data provenance, time range, national scope, supported dimensions, and usage examples. Nothing material is missing for an agent to select and invoke 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%, so the parameters are already fully documented in the schema. The description reinforces origin and commodity usage with examples like China vs India on auto parts and furniture from Vietnam, but it does not add syntax or constraints beyond what the schema already provides, and it does not explain the months parameter.

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 resource and scope: US tariff duty receipts showing what importers actually paid by origin, commodity, and month. It distinguishes itself from rulebook-style lookups by emphasizing official receipts and 'not the rulebook,' so an agent can tell it apart from tariff_lookup.

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 explicitly says to call this tool for any question about what a country actually pays in US tariffs and not to answer from training knowledge. It also gives a clear exclusion — do not calculate the nationwide-duty/gateway-value quotient — and directs the agent to use the matching nationwide burden rate instead.

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