The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Tariff Resolver listing page.
An MCP server that turns your AI assistant into a US import duty research tool — built on official USITC Harmonized Tariff Schedule data (US Government public domain, 35,000+ tariff lines).

Why now: since the de minimis exemption ended (Aug 29, 2025), every US-bound shipment needs an HTS code and duty payment — and 2025–26 rates keep changing by executive order.
Not affiliated with any government agency. Outputs are candidates/estimates for pre-broker screening — not customs, legal, or tax advice. Estimates exclude AD/CVD duties.
Requires Node.js ≥ 18.
Or in any MCP client config:
Claude Desktop (one-click): download tariff-resolver-<version>.mcpb from Releases and double-click it — no terminal needed.
| Tool | What it does |
|---|---|
search_hs_candidates | Product description → top HTS candidates with rates + CBP CROSS ruling links |
calculate_tariff_scenario | HTS code + origin + value (+ weight) → structured JSON: base MFN/FTA rate, candidate Chapter 99 layers with per-layer match/confidence, sourced possibly_expired bucket, MPF/HMF |
watch_tariff_changes | Register HTS codes to a local watchlist |
check_tariff_updates | Diff current vs previous HTS revision — see exactly which rates changed |
dataset_info | Data revision date, row counts, source, license |
The server does the retrieval; your LLM does the reasoning. Chapter 99 rules are returned verbatim (with parsed adder_pct where applicable) so the model reads the actual exception chains instead of trusting a black-box calculation. Rates for 10-digit statistical suffixes inherit from their parent rate line. Headings the schedule marks as dead — terminated, suspended, expired — are filtered out and counted, and the USITC's own compiler_note rides along with any rule that carries one.
Status overrides. data/status_overrides.json is a short, sourced list of Chapter 99 headings whose collection has stopped, expired, or been suspended even though the schedule still prints them. A layer matching an entry is returned under possibly_expired with the entry's status, reason, source URL and as_of date instead of in layers. Every entry carries a CBP, Federal Register or USITC source; pull requests adding entries must include one.
What the data cannot tell you. The published schedule is wrong in both directions at any given moment, so every result carries a stacking_warning and the snapshot date. Provisions whose collection has already stopped keep printing with no end date — IEEPA and Section 122 headings are the recurring case — and newly proclaimed actions appear in the schedule days after they take effect. Totalling every layer the schedule prints yields a rate nobody is charged. Treat the layers as candidates, and verify collection status against CBP CSMS messages before relying on a stack.
One core, two front doors. All duty logic lives in tariff-resolver/core (pure TypeScript, no filesystem or network): resolveDuty(dataset, { hts, origin, value_usd?, ocean? }) — origin takes an ISO-3166 alpha-2 code or an English country name — returns the base line, separate MPF/HMF, every candidate Chapter 99 layer with match and confidence, a sourced possibly_expired bucket, and the snapshot date. The MCP tool calls it; so can any Node or edge runtime. A country name that is not recognised returns the ORIGIN_UNKNOWN error rather than a partial match, so a misspelled origin can never quietly resolve to a thinner stack of layers.
Ships with a full HTS snapshot, fetched from USITC's official JSON API (US Government public domain). Refresh anytime:
dataset_info reports the revision date your queries run against.
tariff-resolver runs entirely on your machine and collects nothing:
scripts/fetch_hts.py refresh script contacts only the official USITC API.)Full policy: https://opsloft.dev/privacy
MIT. Tariff data is a work of the US Government (public domain).