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.