Skip to main content
Glama

Tariff Monitor: US Import Duty & HTS Lookup

Classify a product to HTS codes (description or invoice line)

classify_product
Read-onlyIdempotent

Suggest up to 3 US HTS-10 codes for a product from a product description or an invoice line. Each candidate has: the HTS description from our own HTS data (never written by a model), a one-line reason that quotes that description, a confidence label (high, medium or low), and, when you pass origin_country, the stacked duty from the same logic as calculate_tariff (MFN + Section 301 + Section 232 + the 2026 forced-labor layer). How it works: candidates are retrieved only from our HTS data; a self-hosted model on our own server (no outside AI provider) ranks only among those candidates, and any code that is not in our data is dropped. These are SUGGESTIONS TO VERIFY, not a classification ruling: binding rulings come from US Customs and Border Protection (CBP, https://rulings.cbp.gov/), and the right line often depends on material, construction and use details a one-line description may not show. Measured on our server: about 1 to 3 minutes per call because the model runs on shared CPU hardware (set a long client timeout); if the model server is busy or unreachable the tool returns a retryable error. Free public endpoint: each call counts as 1 of your 25 daily calls. Running the npm package locally needs your own Ollama server (set TM_OLLAMA_URL).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "description": "<description>"
    },
    "name": "classify_product"
  }
}

Input Schema

NameRequiredDescriptionDefault
descriptionYesProduct description or invoice line, e.g. "men's 100% cotton knit t-shirt". Required.
origin_countryNoOptional ISO-2 origin country (e.g. CN, VN, MX). When given, each candidate includes its stacked duty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly/openWorld/idempotent/non-destructive) by disclosing retrieval grounding (candidates only from own HTS data, off-data codes dropped), privacy (self-hosted model, no outside AI provider), latency (about 1-3 minutes per call on shared CPU, set a long client timeout), failure mode (retryable error when the model server is busy), and a 25-calls-per-day rate limit. It also names the authoritative alternative (CBP binding rulings) and explains why a one-line description may misclassify.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then output shape, then mechanism, then caveats, then operational constraints — a sensible order with little redundancy. It is a long single block, and the trailing npm/TM_OLLAMA_URL sentence is deployment detail of marginal value to an agent deciding whether to call it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so by naming every candidate field. Combined with latency, rate limits, failure behavior, and the 'verify with CBP' caveat, an agent has everything needed to call this correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters; the description still adds real meaning by spelling out that origin_country (ISO-2) triggers a stacked duty computed with the same logic as calculate_tariff (MFN + Section 301 + Section 232 + 2026 forced-labor layer). That is behavior the schema does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource plus scope: "Suggest up to 3 US HTS-10 codes for a product from a product description or an invoice line." It also enumerates the shape of each candidate (HTS description, reason, confidence label, optional duty), so an agent knows exactly what comes back and can tell this fuzzy-classification tool apart from an exact-code lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear usage context: input is a one-line description or invoice line, results are "SUGGESTIONS TO VERIFY" not a ruling, and passing origin_country opts into duty stacking. It does not explicitly route the agent away from siblings such as lookup_hts_code (when a code is already known) or compare_origins, so there is no explicit exclusion set.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.