Maps a product name or description to Harmonized System / HTS customs classification codes — the lookup customs brokers, import/export compliance teams, and trade-automation agents need before filing a shipment or estimating duty. Returns ranked HS/HTS candidates. Pay-per-call via x402 (USDC on Base): $0.03/call, no account or API key. tools/list and /openapi.json are free for discovery.
Scored across 2 tools
Both tools perform the same classification operation, so there is conceptual overlap, but the single vs. bulk distinction is clear and the descriptions explicitly differentiate them. An agent would not struggle to pick the right one based on input size.
The naming follows a clear and consistent pattern: 'classify' for a single call and 'classify_bulk' for the batch variant. Both use the same verb and the suffix cleanly communicates the difference.
With only two tools, the server is slightly under the typical 3-15 range, but the scope is narrow and the pair covers both individual and bulk classification needs. No redundant or unnecessary tools exist.
The tool surface fully covers the stated purpose of HTS classification through both single and batch modes. Minor gaps exist, such as no direct HTS lookup or schedule browsing, but these are outside the core classification workflow.
Classify a product description into candidate HS/HTS10 tariff codes. Deterministic BM25 retrieval over the USITC HTS schedule with heading-agreement boosting, returning the full parent-chain description, general duty rate, and a score-gap confidence per candidate. Not a customs ruling — always includes a disclaimer to verify with a licensed broker.
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | ||
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description effectively discloses behaviors: deterministic (BM25), heading-agreement boosting, and the inclusion of a disclaimer. It does not explicitly state read-only idempotency, but the operation is clearly a query with no side effects. The description adds value beyond the empty annotations.
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 two sentences, front-loaded with the core purpose. Every sentence adds value: the first states the action and method, the second provides output details and a crucial disclaimer. No redundancy or excessive detail.
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?
Given no output schema, no annotations, and only two parameters, the description covers the tool's purpose, algorithm, and output fields. However, parameter semantics are missing, which reduces completeness. For a query tool with this complexity, it is adequate but not excellent.
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 0%, so the description must explain parameters. While 'description' is obvious, 'options.top_k' and 'options.origin_hint' are not elaborated. The description mentions 'score-gap confidence' but doesn't link to parameters. This is a significant gap that could hinder correct invocation.
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 clearly states the tool's function: 'Classify a product description into candidate HS/HTS10 tariff codes.' It specifies the retrieval method (deterministic BM25), the data source (USITC HTS schedule), and the output fields (parent-chain description, duty rate, score-gap confidence). The disclaimer distinguishes it from a customs ruling, clarifying its non-authoritative nature.
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 explains what the tool does and includes a disclaimer that it is not a customs ruling, implying verification is needed. It specifies the algorithm and data source, giving context for when to trust the results. However, it does not explicitly mention when not to use the tool or suggest alternatives, but with no sibling tools, this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify up to 100 product descriptions in one paid call — one payment covers the whole batch (per-item discount vs calling classify N times). Deterministic BM25 retrieval over the USITC HTS schedule, same as classify. Not a customs ruling — always includes a disclaimer to verify with a licensed broker.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| options | No |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
classify_bulkclassify
Add one secure layer between your agents and this server.