How AI agents classify products and compute landed cost

Ask a general-purpose language model for an HS code and it will give you one — confidently, instantly, and quite often wrong. Ask it for a duty rate and it does the same thing, because that's what language models do by default: produce the most statistically plausible answer, not the verified one. For a chatbot, that's a minor annoyance. For an AI agent about to file a customs entry or price a product for a buyer, a fabricated HTS code or a stale Section 301 rate is the kind of error that shows up as a CBP penalty notice three months later.

This is a guide for developers building AI agents, and for the agents themselves reading it: how to turn a plain-English product description into a sourced HS/HTS code and a full landed-cost breakdown, using PortRobin's public JSON API and its MCP server, without letting the model invent a single number it shouldn't.

The two-part problem: classification vs rating

Getting from "product" to "landed cost" is really two separate jobs with different trust models. Classification — turning "men's cotton hoodie" into 6110.20.2079 — is a judgment task. It benefits from AI, provided the model is grounded in the actual heading text and the General Rules of Interpretation rather than pattern-matching on vibes. Rating — turning that code plus a country of origin into a duty percentage — is a lookup task, and there is exactly one acceptable source for a duty figure: the current published schedule, not a model's training data.

PortRobin's engine keeps that split explicit at the architecture level. The classification endpoint calls an AI provider, when one is configured, to reason about candidate codes and explain its match. Once a code is chosen, every dollar figure attached to it — the general rate, Section 301/232/IEEPA measures, MPF, HMF — comes from a maintained dataset of record, never the model's output. The two paths never cross.

Why build a customs API for AI agents?

Import compliance is an unusually good fit for agentic automation, and a bad fit for an LLM working alone. It's a good fit because the task is repetitive, structured and high-volume — a checkout app estimating landed cost might need a classification for every new SKU a merchant lists. It's a bad fit for an unaided model because the underlying data changes constantly. Section 301 lists get amended, IEEPA measures get added or suspended, and the $800 de minimis exemption has moved more than once in the past two years. A model trained months ago simply doesn't know that.

A dedicated customs API solves that by putting a live, sourced dataset behind a stable interface the agent calls at run time, instead of relying on frozen training data. Picture a three-person team building a Shopify app that shows shoppers an estimated landed cost before checkout. They don't want to hand-maintain a tariff table for forty thousand SKUs across a dozen origin countries — they want to call one endpoint with a description and an origin, and get back a number refreshed every time a merchant adds a new listing.

Classifying a product with the HS code classification API

The classification endpoint takes a product description — and, optionally, a country of origin — and returns ranked HTS candidates rather than a single answer. Each candidate carries the heading text, a plain-English gloss of what it covers, and the reasoning behind the match, so your agent can present the top result, ask a clarifying follow-up question ('is this knit or woven?'), or fall back to a broader heading when confidence is low. That's the same workflow a human classifier follows; the API just runs it in under a second.

• Request: a description string ("women's knit cotton t-shirt") and an optional two-letter origin code.
• Response: an array of candidates, each with a code, a confidence score, and the reasoning behind the match.
• Each candidate also carries its sourced general rate, so you don't need a second call just to see the headline duty.
• No AI provider configured on your account? The endpoint degrades to deterministic keyword matching and says so explicitly via a needsProvider flag — it never silently guesses.

Computing landed cost with the API

Once you have a resolved HTS code, pass it — with the customs value, origin, freight, insurance and transport mode — to the landed-cost endpoint. It looks up the base rate, layers on the Section 301, 232 and IEEPA measures that currently apply to that origin, adds the Merchandise Processing Fee and, for ocean freight, the Harbor Maintenance Fee, and returns an itemised breakdown. Every line is tagged with a source and a verification date, and any rate the dataset can't confirm comes back null rather than estimated.

That itemisation matters more to an agent than a headline total does. An agent that only gets "landed cost: $8,255" can't explain where the number came from if a user pushes back. An agent that gets product cost, freight, base duty, Section 301 duty, MPF and HMF as separate sourced lines can answer the follow-up question — usually "why is duty so high" — without another round trip.

What's the difference between the REST API and the MCP server?

PortRobin exposes the same underlying engine two ways, and most teams will end up using both. The REST API is a set of plain JSON endpoints you call from your own backend or app — the natural choice if you're building a checkout widget, a spreadsheet plugin, or a cron job that revalidates SKUs overnight. The MCP server exposes the identical capabilities as tools an agent framework can call natively — the natural choice when the caller is a conversational agent (Claude, or any client that speaks the Model Context Protocol) rather than your own code.

Either way, the response carries the identical sourced-or-null contract, so an agent reasoning about whether it has a trustworthy number behaves the same regardless of which transport it used to get there. PortRobin's MCP server currently exposes five tools:

• classify_product — a plain-English description in, ranked HTS candidates with reasoning and sourced rates out.
• lookup_duty — an HTS code and origin in, the base rate plus stacking Section 301/232/IEEPA measures out.
• compute_landed_cost — customs value, code and origin in, an itemised sourced breakdown (duty, MPF, HMF, freight, insurance) out.
• get_hts_code — one HTS code in, its official description, general rate and applicable measures out, all cited.
• search_hts — a keyword or partial code in, matching HTS lines with their general rates out.

How does llms.txt help AI agents discover PortRobin?

llms.txt is an emerging convention — a plaintext file at the root of a site, written for language models rather than search crawlers, that summarises what the site does and where its machine-readable surfaces live. PortRobin's llms.txt lists every REST endpoint, every MCP tool, the honesty contract, and the free tools that need no login, in a format an agent can parse in a single pass rather than scraping rendered HTML. It's the difference between an agent guessing at your API shape from a marketing page and an agent reading a spec.

This matters more than it sounds. As more traffic arrives via an AI agent acting on a user's behalf rather than a person clicking a search result, agent-readable output stops being a nice-to-have and starts being the primary interface. A customs API only a human can discover, by reading prose on a docs page, is invisible to an agent scanning llms.txt files across candidate providers to decide which one to call.

Why the honesty contract matters for agents

As one licensed customs broker put it during a recent CBP trade compliance webinar, the classifications that cause real problems are rarely the obviously wrong ones — they're the confident-sounding wrong ones nobody double-checked before filing.

An agent is only as trustworthy as the worst number it will confidently repeat. If your agent calls a source that fills gaps with plausible guesses, every downstream decision it makes — a quoted landed cost, a sourcing recommendation, an entry it helps prepare — inherits that risk silently. Returning null instead of a fabricated rate lets the agent do the right thing instead: flag the uncertainty to the user, suggest a binding ruling request, or route the case to a licensed customs broker. That's the difference between an agent that helps an importer and one that gets them fined.

None of this is legal, customs or tax advice, and nothing an agent generates from these endpoints substitutes for a CBP ruling or a licensed customs broker's review before you actually file an entry. Treat every response as an informational estimate to be verified, not a filing-ready determination.