US Tariff Lookup

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

With no annotations, the description carries the full burden and does disclose real behavior: a free-trade rate is surfaced separately when origin qualifies, and excluded items are called out instead of being folded into a total that looks complete. It does not cover rate limits, error behavior, or required permissions, but the disclosure of output shape and limitations is unusually candid.

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?

Three sentences, front-loaded with the core operation and zero filler. The closing caveat about not using it as a declaration is the longest element but it is the one that prevents misuse, so it earns its place.

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?

With no output schema, the description does the work of explaining that the return is an indicative duty with a separately shown free-trade rate, which is the key return-value information. What is missing is how the estimate should be interpreted alongside the sibling lookup tools, but for a three-parameter computation tool this is close to complete.

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 schema already defines hts_code, origin_country, and customs_value_usd. The description only implicitly links origin_country to the separate free-trade rate and adds no format or syntax detail beyond the schema, so the 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?

It states a precise verb and resource: applies the governing ad valorem rate for an HTS code to a customs value and returns the indicative duty. An agent can tell it is a computation rather than a lookup, unlike find_hts_code or lookup_us_duty_rate, though no sibling is named explicitly.

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 a clear positive cue ('use it for a directional landed-cost figure') and an explicit exclusion ('never as a customs declaration'). It stops short of naming the sibling tools it should be combined with or preferred over for rate lookup, so routing between the three tools is left partly to inference.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the most important trait: the tool deliberately returns multiple candidates with their descriptions instead of a single answer, and it surfaces duty rates in the result. It does not cover authority/permissions, rate limits, pagination, or the meaning of the limit cap beyond what the schema already says.

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?

Two sentences, front-loaded with what the tool does and what it returns. The second sentence is slightly long but earns its place by explaining the deliberate multi-candidate design, which is the key behavioral fact an agent needs.

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 two-parameter read tool with no output schema and no annotations, the description covers intent, input form, and the nature of the return (candidate lines plus duty rates). It is nearly complete; only the limit behavior and any ordering/ranking of candidates are left unstated.

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 both parameters are already documented in structured form, establishing a baseline of 3. The description reinforces that 'description' is plain words but adds no new syntax, format, or constraint detail beyond the schema, and says nothing extra about 'limit'.

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 gives a specific verb (search), a specific resource (the official US Harmonized Tariff Schedule), an input form (plain-language product description) and a return shape (candidate HTS lines with duty rates). It does not, however, differentiate itself from the siblings lookup_us_duty_rate and estimate_us_duty, which also deal with duty rates, so the agent must infer the division of labor.

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 implied by the framing that 'classification is the hard part of importing', indicating this is the classification step rather than a rate lookup or a duty estimate. But no sibling is named, no when-not condition is given, and no prerequisite (e.g., you must obtain a code before estimating duty) is stated, so the routing decision is left to inference.

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

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

With no annotations, the description carries the full burden and delivers meaningful domain behavior: the 8-digit vs 10-digit inheritance trap, that exclusions are always reported, and that Section 301-type remedies are absent from the data and can dwarf the base rate. It stops short of return format, error handling, or rate limits, but the disclosed caveats are exactly the ones an agent could otherwise get wrong.

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?

Three sentences, each earning its place, with the core verb+resource front-loaded. The inheritance clause is long but conveys non-obvious domain behavior that prevents a wrong answer.

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 two-parameter read tool with no output schema or annotations, the description covers the substantive pitfalls: rate inheritance, exclusions, and FTA checking. It does not mention behavior on malformed or partial codes (e.g., '6212'), which the schema implies is supported.

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 explains that origin_country drives free-trade eligibility, so the description largely restates it. The dot-optional HTS formats are only documented in the schema, not the description. Baseline 3 applies when the schema does the heavy lifting.

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 names a specific verb+resource ('Given a US HTS code, returns the duty rate that actually applies') and the scope is unambiguous. It implicitly separates itself from an estimation tool by stressing the 'actually applies' rate, but it never names the siblings estimate_us_duty or find_hts_code, so differentiation is left to inference.

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 one concrete usage hint — pass origin_country to check free-trade eligibility — and scopes out trade remedies, but it never states when to prefer this over estimate_us_duty or when to use find_hts_code first. Usage is implied rather than routed.

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