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

Far exceeds the annotations: it enumerates exactly what is returned (base rate, each stacked layer, total, data-checked date, notes), which programs are computed versus merely flagged as 'needs review' (vehicles, wood, trucks, semiconductors, drones), and which are explicitly not computed (Section 338 Canada lists published only as images, IEEPA tariffs ended 20 Feb 2026). It also discloses accuracy caveats ('Figures are estimates') and that 8- then 6-digit fallback may occur, so the agent knows the answer may be for a different code than requested.

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?

One enormous run-on sentence carries hundreds of words of legal citation detail — FR Doc numbers, the exclusion end date stated twice in 'both official wordings', heading ranges, exact percentages per program. Much of this is reference minutiae that does not help an agent decide to call the tool, and it buries the useful parts (returns, notes, estimates) mid-paragraph.

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 calculation tool with 100% schema coverage and no output schema, the description is more than complete: it explains return values, caveats, and known non-computed cases. The only shortfall is structural — the completeness is achieved through density rather than organization, and sibling routing is absent.

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 all three parameters are already documented in the schema, including the CN default and the annual-value option. The description only restates that dollar impact is optionally computed, adding no format or interpretation detail beyond what the schema provides; baseline 3 applies.

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 opening sentence states a precise verb and resource: calculate a stacked US import tariff rate for an HTS code from an origin country. That is unmistakably different from lookup_hts_code, but the description never names the siblings or explicitly contrasts itself with compare_origins, so the differentiation is left implicit.

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?

Usage is only implied: an agent infers it should call this when it has an HTS code and origin and wants a total rate. There is no explicit 'use this instead of compare_origins when...' routing, no statement of prerequisites, and no guidance on when a rate lookup is inappropriate (e.g. a code that must be resolved first with lookup_hts_code).

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