Freight MCP Servers 2026: A Teardown (Warp, CargoMART)

Server	Runs as	Tools	Booking needs	Quote validity	Scope
Warp `warp-agent-mcp`	stdio via npx	~23	API key	~72 hours	Road, own network
CargoAi CargoMART	hosted	search, quote, book	account auth	short window	Airfreight
freightutils-mcp	stdio via npx	~19	none (read only)	not applicable	Calculations, reference
Easyship	hosted or stdio	rates, labels, tracking	API key	carrier dependent	Parcel

A few months ago I wrote a primer on how the Model Context Protocol maps onto a freight API, including a minimal server you can run yourself. MCP is the open standard Anthropic published in November 2024, and freight was slow to adopt it until early 2026. Since then the talking stopped and the shipping started. Warp published warp-agent-mcp to npm on 16 April 2026 under an MIT licence, CargoAi launched its CargoMART server on 5 June 2026, and open-source and parcel servers landed alongside them. This is the follow-up I wanted to read: a teardown of what actually shipped, where these four agree, and where the design choices quietly diverge. If you have not seen the protocol basics, start with that primer and come back here.

The servers that actually shipped

Warp warp-agent-mcp reached npm on 16 April 2026, MIT licensed, billed as the first MCP server for booking real freight. It exposes roughly 23 tools spanning search, quoting, booking and tracking against Warp's own managed road network.
CargoAi CargoMART shipped on 5 June 2026, letting an agent search, quote and book airfreight from inside Copilot, ChatGPT, Claude or Gemini. It is the clearest sign the air side is moving, not only road.
freightutils-mcp is the open-source option, a TypeScript package with about 19 free utility tools. It leans toward calculations and reference data rather than transacting on a live network, which makes it a clean sandbox.
Easyship targets parcel and small-package work across its 550-plus courier integrations, surfacing rates, label creation and tracking. It is parcel-first, so its modelling assumptions differ from heavy freight.

Read side by side, the four diverge on three questions: what the agent can do without credentials, how long a price lasts, and where the server runs.

Tool surface: what the agent is allowed to do

Every server is a bag of tools, and the bag tells you the vendor's intent. Warp's roughly 23 tools are the widest set because it is built to transact end to end, from a capacity search to a tracking lookup. CargoMART centres on the air booking journey, exposing search, quote and book. freightutils stays in calculation and lookup territory across its 19 utilities. Easyship optimises for the parcel rate-to-label loop with rates, labels and tracking.

When I map these onto a freight workflow, the tools cluster into four jobs: finding capacity, pricing it, committing to it, and watching it move. The first two only read, so they are low risk. Committing writes to the real world and spends money. Watching is read-only again but high value, because most human time still goes into chasing status.

An agent discovers what a server offers through the MCP tools/list method and invokes a tool with tools/call, so the names it reads back matter. Names that describe outcomes a dispatcher recognises, such as get_quote, book_shipment or get_tracking, survive contact with a real agent. Names that leak raw endpoints force the model to orchestrate plumbing, and that is where invented parameters creep in. Warp and CargoMART both lean to outcome-shaped names, which is a quiet signal they were designed for agents rather than retrofitted from a REST spec.

Authentication: open quoting, gated booking

The shared pattern across the serious servers is the one I would have chosen myself. Quoting and reference tools are open or low-friction, because letting an agent price a lane is harmless and genuinely useful. Booking, cancelling and anything that touches an invoice sits behind an API key or a full OAuth flow. Warp, for example, reads its key from a local config file at ~/.warp/config.json, so the booking tools light up only when you are authenticated.

{
  "mcpServers": {
    "warp": {
      "command": "npx",
      "args": ["-y", "warp-agent-mcp"],
      "env": { "WARP_API_KEY": "your_key_here" }
    }
  }
}

Without the key the agent can still explore and quote. With it, the agent can spend money on your behalf. For desktop use a static key in a config file is acceptable. For a production agent that books unattended, a static key is a liability, and you want OAuth 2.1 with PKCE and scoped, revocable tokens so a compromised agent cannot rebook or cancel at will. I will go deeper on that in a dedicated security piece, because freight booking turns an ordinary prompt-injection into a money event.

The quote-validity trap

Here is the detail that bites teams new to freight. A quote is not a price, it is a price with an expiry. Warp's quotes, for instance, carry a validity window of around 72 hours, not days. An agent that quotes on Monday and tries to book on Friday will fail, and a naive retry loop will keep failing while burning tokens.

So the server has to make validity machine-readable, and your agent has to respect it. The good implementations return an explicit expiry and a quote reference, and the booking tool checks both. The weaker ones return a bare number and leave you to guess. When you evaluate a server, quote a lane, wait, and then try to book against the stale quote. How it fails tells you how much production hardening went in.

Transport: stdio versus hosted HTTP

The protocol defines two transports, stdio and Streamable HTTP, and the messages are JSON-RPC 2.0 either way. A local stdio server, launched with npx, is perfect for a developer wiring a desktop assistant such as Claude Desktop or Cursor to their own account. Setup is trivial and the credentials never leave the machine. A hosted HTTP server runs as a service, which is what you need when a fleet of agents shares access, when you want central logging, and when you cannot scatter API keys across laptops.

freightutils and the npx-launched servers make the local path effortless. Production deployments lean to hosted HTTP behind a gateway that handles auth, rate limits and an audit trail. Neither is wrong. The mistake is shipping a stdio prototype into production and discovering you have no central view of what your agents booked.

What a multi-carrier marketplace server has to expose

This is where my own perspective comes in, because we run a marketplace rather than a single carrier, and the modelling problem is genuinely different. A single-carrier server answers one question: can I move this, and for how much, on my network. A marketplace server has to answer a harder one: across many carriers, which option should the agent pick, and why.

That forces tools a single-carrier server never needs. The agent has to be able to compare offers, not just fetch one. It needs a ranking signal that blends price with transit time and carrier availability, because the cheapest quote on a lane nobody is currently serving is a trap. It needs honest availability, so the agent does not commit to capacity that has already gone. And it needs the booked shipment to reconcile back to a specific carrier and reference, so tracking actually resolves. On a busy lane an agent might see a dozen quotes and find only three or four bookable that day, and in our data the gap between the cheapest quote and the cheapest bookable quote is real and recurring. A marketplace server that hides that gap is doing the agent a disservice. The lesson we keep relearning is that a price without availability is marketing, not a booking.

How to evaluate a freight MCP server

If you are choosing one, run this short checklist against the live server rather than the landing page.

Tool names. Do they describe outcomes a dispatcher recognises, or do they expose raw endpoints?
Credential boundary. What works without a key, and what does booking require? Is there a path to scoped OAuth for unattended use?
Quote validity. Is expiry returned explicitly, and does the booking tool reject a stale quote cleanly?
Transport. Local stdio for desktop, hosted HTTP for a fleet. Does the vendor support the one you actually need?
Coverage honesty. Single carrier or many, and if many, can the agent see availability and a ranking rather than one opaque number?
Observability. Can you audit what an agent quoted and booked after the fact?

The market moved from think-pieces to packages in a single quarter, which is fast even by logistics-tech standards. If you are building, the primer plus this teardown should be enough to wire an agent to a real network this week. If you are buying, the checklist above will separate a booking engine from a demo. On a marketplace like GetTransport the same principles decide whether an agent can be trusted to spend money, and that trust is built on availability and validity, not on the size of the tool list.

FAQ

What is a freight MCP server?

It is a small service that exposes freight actions, such as quoting, booking and tracking, as tools an AI assistant can call through the Model Context Protocol, so the agent integrates once instead of learning every carrier API.

Which freight MCP servers exist in 2026?

The notable ones include Warp's warp-agent-mcp for road freight booking, CargoAi's CargoMART for airfreight, the open-source freightutils-mcp for calculations and reference data, and Easyship for parcel rates and labels.

Can an AI agent book freight without an API key?

Usually not. Most servers let an agent quote and look up data without credentials, but booking, cancelling and invoice actions require an authenticated key or an OAuth token so only authorised agents can spend money.

Why do freight quotes returned by an MCP server expire?

Freight prices move with capacity and fuel, so a quote is valid only for a short window, sometimes a few hours. The server returns an expiry, and the agent should rebook a fresh quote rather than retry a stale one.

What should a marketplace MCP server expose that a single-carrier one does not?

It should let the agent compare offers across carriers, see a ranking that blends price with transit time and availability, and reconcile a booking back to a specific carrier, because the cheapest quote is not always the one you can actually book.