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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that the call is paid, that one payment covers the whole batch, that retrieval is deterministic BM25 over the USITC HTS schedule, and that a disclaimer is always included. This is substantial behavioral context. It does not mention rate limits, error behavior, or exact response format, but the disclosed traits are highly relevant for an agent deciding whether to invoke this tool.

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 three sentences with no wasted words. It front-loads the core action and batch limit, then adds the pricing distinction, the retrieval method, and the legal disclaimer. Every sentence earns its place and the structure is easy to scan.

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 batch tool with no output schema and no annotations, the description covers the key operational facts: batch size, pricing, retrieval method, and disclaimer. It does not describe the return format or how results map to input items, which an agent might need to know, but the core invocation context is well covered. The missing parameter semantics for `options` are a minor gap, so a 4 is justified.

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 0%, so the description must compensate for the schema's lack of parameter documentation. The description explains the `items` parameter implicitly (product descriptions to classify) and the batch limit, but it does not explain `options.top_k` or `options.origin_hint` at all. The schema provides names, types, and constraints, but the description adds no meaning for the nested options object. This is a partial gap, so a 3 is appropriate.

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 verb ('Classify'), a resource ('product descriptions'), a batch limit ('up to 100'), and a pricing model ('one paid call'). It also explicitly distinguishes itself from the sibling tool `classify` by noting the per-item discount and identical retrieval method. An agent can clearly understand what this tool does and how it differs from `classify`.

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?

The description explicitly names the alternative (`classify`) and provides a clear condition for choosing this tool: when you have up to 100 items and want a per-item discount. It also states what this tool is NOT ('Not a customs ruling') and advises verification with a licensed broker, which helps an agent decide when to use it and what caveats to communicate.

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