What is llms.txt — and why customs tools need one

Ask an AI shopping assistant to price out importing a batch of wireless earbuds from Shenzhen, and increasingly it won't open a browser at all. It reaches for a tool instead — a live source it can query directly — rather than guessing from whatever it read during training. Two ideas sit behind that shift: llms.txt, a plain-text file that tells an AI agent what's actually worth reading on a site, and the Model Context Protocol (MCP), a standard that lets an agent call a site's data and functions directly. Neither is exotic. Together, they're quietly becoming as ordinary to a modern website as robots.txt or a sitemap.

What is llms.txt?

llms.txt is a proposed convention for giving AI agents and large language models a clean, curated index of a website's most useful content, published as plain Markdown at a predictable location — /llms.txt, at the site root. The idea, put forward publicly in 2024, borrows directly from robots.txt and sitemap.xml: a small file in a fixed place that tells an automated visitor where the good stuff is, rather than making it crawl and guess. Where robots.txt says what a crawler is allowed to fetch, llms.txt says what an AI agent should actually read first — a short, hand-picked list of pages, docs and data endpoints, described in plain language rather than buried inside navigation menus and marketing copy.

Why would a site need this at all?

Because scraping rendered HTML is a slow, lossy way for an agent to learn what a site does. A typical product page is built for a human eye — hero image, navigation bar, cookie banner, three paragraphs of marketing copy before the one fact that matters. A language model parsing that page burns effort on layout noise and has no reliable way to tell a stale blog post from a live data feed. llms.txt strips that away: just links and one-line descriptions, ordered by what an agent actually needs first. A growing number of developer-tools companies — documentation platforms, API providers, a handful of SaaS products — already publish one, and AI-answer engines are starting to look for it the way search engines have looked for a sitemap for two decades.

What is the Model Context Protocol, and how is it different from an API?

llms.txt solves discovery — it tells an agent where to look. It doesn't solve execution, which is actually doing something with that information. That's where the Model Context Protocol comes in. MCP is an open standard, released by Anthropic in late 2024, for exposing a site's tools and data to an AI agent in a structured, machine-callable way. Instead of an agent guessing at an API's shape from prose documentation, or worse, trying to fill in a web form meant for a human, an MCP server publishes a fixed schema of tools — classify a product, look up a duty rate, calculate a landed cost — that any compliant agent can call directly, with typed inputs and typed outputs.

A five-person sourcing-software team in Austin found this out the hard way. They wired an early AI copilot for their DTC clients to a partner's REST API, and every time a tariff schedule changed, someone had to read the release notes, patch the integration and redeploy before the numbers could be trusted again. When they moved the same copilot onto an MCP-based tool call instead, that maintenance loop mostly disappeared — the tool always returns the current rate, sourced and dated, without anyone touching the integration code.

Why does this matter specifically for customs and tariff data?

Most of what a language model knows, it learned once, during training, and that knowledge has a cutoff date. That's a reasonable trade-off for explaining how tariffs work in general. It's a genuinely dangerous one for stating what a specific tariff rate is today, because Section 301, Section 232 and reciprocal tariff actions move through individual Federal Register notices — sometimes with weeks of notice, sometimes with almost none. A model trained on data through late 2025 has no way of knowing about a Section 301 exclusion that lapsed in March 2026, or a new derivative product added to a Section 232 list in May. Ask it directly and it will often answer anyway — fluently, confidently, and wrong.

This is exactly the class of problem tool-calling was built for. Picture an AI sourcing agent helping a small electronics brand decide whether to source a Bluetooth speaker component from Vietnam or Malaysia. Asked to estimate the landed-cost difference, a model working from memory alone might quote last year's duty rate, miss an added tariff layer entirely, or sound completely certain while doing both. An agent wired to a live tool instead sends the HTS code and country of origin to a landed-cost endpoint, gets back a rate sourced to a dated schedule, and can tell the brand exactly when that figure was last verified. One approach is a guess dressed up as an answer. The other is a lookup — which is what the question actually needed all along.

Customs brokers who've started testing AI sourcing tools describe the same worry from a different angle: a model that sounds certain is more dangerous than one that admits it doesn't know, because nobody double-checks a confident-sounding answer. The tools worth trusting are the ones that say 'verify this' when they should, rather than filling the gap with something plausible.

llms.txt, MCP or a traditional API — what should a site actually build?

These aren't competing options so much as different layers of the same problem. An agent first has to find out that a capability exists, and then it has to be able to act on it without a human writing custom glue code in between. Plain HTML with good SEO covers discovery for humans and search crawlers, but leaves an agent guessing. A traditional REST API covers execution, but only after a developer has read the docs. llms.txt and MCP together cover both steps for an agent specifically — which is why sites built with AI-agent traffic in mind are increasingly shipping both rather than treating them as optional extras.

What this looks like in practice

On PortRobin, the /llms.txt file works as a short map: it tells an agent that classification, duty lookup and landed-cost calculation exist as callable tools, points at the API docs, and links to the MCP server for agents that support it. The MCP server then exposes those same capabilities as native tools — classify a product description, look up an HTS line, calculate landed cost — each returning a sourced figure and a verification date, or an explicit flag to check the number rather than a smoothed-over guess. An agent doesn't need to parse a webpage to work any of that out; it reads the index, calls the tool, and gets an answer it can actually stand behind.

If you're comparing this against other ways of getting classification data into an application, it's worth looking at how different providers structure their APIs, because the tool-calling layer is only as good as the data and honesty rules underneath it.

Is llms.txt an official web standard yet?

Not formally, no, and that's worth being upfront about, because the AI-tooling space moves fast and it's easy to overclaim. There's no IETF RFC or W3C recommendation for llms.txt the way there is for the robots exclusion protocol or the sitemap format; it's a grassroots convention that a growing number of developer-facing sites have adopted because major AI labs and answer engines have started looking for it. MCP is on firmer ground: it has a published specification, a growing list of adopting platforms, and support built into several major agent frameworks. Neither guarantees an AI agent will surface a given site's data. Skipping both is simply a bet that agents will keep reading a business the slow, lossy way indefinitely.

That last point matters more in trade compliance than almost anywhere else, because the underlying facts genuinely move. Tariff schedules get updated through official notices, not press releases, and the pace of Section 301 and 232 actions over the past few years means a rate that was correct in January can be stale by June. Nothing in this article is legal, customs or tax advice — treat any duty figure, from a model or otherwise, as a starting point to verify against the current schedule before you rely on it for a filing.