| What it is | An open standard that lets AI agents call your freight systems |
| Protocol | JSON-RPC 2.0 over stdio or HTTP |
| Core building blocks | Tools (actions), Resources (read-only data), Prompts (templates) |
| Freight use cases | Quote, book, track, pull BOL/POD, audit invoices |
| Live in 2026 | Warp, CargoAi CargoMART, FreightUtils, C.H. Robinson |
| One integration | Works across Claude, ChatGPT, Copilot, Gemini, Cursor |
For years, every time we connected freight software to a new partner it meant another bespoke API project, and I have watched teams rebuild the same plumbing for each tool. In 2026 a second integration surface has appeared: the Model Context Protocol (MCP), an open standard that lets an AI agent inside Claude, ChatGPT, Microsoft Copilot or Gemini call your freight systems directly. Instead of a person clicking through a portal, the agent asks for a quote, books a load or pulls a proof of delivery in plain language. This guide explains what MCP is, how it maps onto a freight API, and shows a minimal working server. I will also walk through who is already running it in production, and where I think you should be careful.
What is MCP?
The Model Context Protocol is an open specification, originally released by Anthropic and now developed with the wider community, for connecting AI models to external tools and data. It standardises the "wire format" between an AI client and your software so you build the connection once rather than re-implementing it for every assistant.
Technically, MCP speaks JSON-RPC 2.0 over either a local stdio transport or a remote HTTP transport. A server declares three kinds of capability when an agent connects:
- Tools — executable actions the model can invoke, such as querying an API or running a calculation. Tools are model-controlled: the agent discovers them and decides when to call them.
- Resources — read-only data the application exposes for context, such as a rate table, a carrier list or a shipment document. Your application, not the model, decides when to attach them.
- Prompts — reusable, user-controlled templates (for example, "plan a multi-stop LTL run") that a client can list and fill in.
Each capability has standard list and call/get methods, which is exactly why one MCP server works in any MCP-compatible client without custom glue per assistant.
Why MCP matters for freight specifically
Logistics is a coordination problem across many systems: a transportation management system (TMS), carrier APIs, rating engines, track-and-trace, customs data, ERP. Historically each AI feature meant a separate integration, and each new assistant meant doing it again. MCP collapses that. You expose your freight capabilities once as an MCP server, and any agent can quote and book through them, then track whatever is moving.
The practical payoff is the same one shippers already get from freight booking software and modern APIs, namely fewer manual portal steps, but extended to natural-language workflows. In practice an agent strings several calls together. It reads a rate Resource, calls a get_quote Tool, then checks a tracking Tool and surfaces the result, all inside one conversation.
Mapping a freight API onto MCP
The cleanest way to design a freight MCP server is to sort each capability into the three primitives:
- Tools (actions):
get_quote,book_load,track_shipment,get_documents(BOL/POD),audit_invoice. - Resources (read-only context): the carrier list, lane rate cards, accessorial fee tables, a shipment's status history.
- Prompts (templates): "compare LTL vs FTL for this load", "find the cheapest compliant carrier for dangerous goods".
A useful rule of thumb: anything that changes state or costs money is a Tool that should require confirmation; anything that is reference data is a Resource the agent can read freely.
A minimal freight MCP server (worked example)
Below is a stripped-down TypeScript sketch of an MCP server exposing two freight tools. It uses the official SDK and a JSON Schema for each tool's inputs, then calls your existing freight API under the hood:
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";
const server = new McpServer({ name: "freight", version: "1.0.0" });
// Tool 1 — quote a shipment (read-only, safe to auto-run) server.tool( "get_quote", { origin: z.string(), destination: z.string(), weightKg: z.number(), mode: z.enum(["ltl", "ftl", "van"]) }, async ({ origin, destination, weightKg, mode }) => { const r = await fetch(`https://api.example-freight.com/v1/quotes`, { method: "POST", headers: { authorization: `Bearer ${process.env.FREIGHT_TOKEN}` }, body: JSON.stringify({ origin, destination, weightKg, mode }), }); const data = await r.json(); return { content: [{ type: "text", text: JSON.stringify(data) }] }; }, );
// Tool 2 — track a shipment (read-only) server.tool( "track_shipment", { shipmentId: z.string() }, async ({ shipmentId }) => { const r = await fetch(`https://api.example-freight.com/v1/shipments/${shipmentId}`, { headers: { authorization: `Bearer ${process.env.FREIGHT_TOKEN}` }, }); return { content: [{ type: "text", text: JSON.stringify(await r.json()) }] }; }, );
server.start(); // stdio by default; HTTP transport for remote agents
An agent connected to this server can now answer "How much to move 800 kg LTL from Lisbon to Madrid, and where is shipment ABC123?" by calling both tools and composing the reply. A book_load tool would follow the same shape — but, as covered below, gated behind explicit human confirmation because it commits money.
Who is already running freight MCP in 2026
This is no longer theoretical. Concrete production deployments appeared through the first half of 2026:
- Warp published warp-agent-mcp to npm on 16 April 2026, described as the first production MCP server for freight. Its 23 tools quote and book LTL/FTL shipments, pull BOL/POD documents, audit invoices and report tracking, all on its live network rather than a sandbox.
- CargoAi connected its CargoMART air-cargo booking platform to Copilot, ChatGPT, Claude and Gemini via MCP on 5 June 2026, letting forwarders quote and book airfreight in plain language.
- FreightUtils offers an open MCP server with 19 free tools, covering ADR dangerous-goods lookup, HS-code search, chargeable-weight and CBM/LDM calculators, pallet fitting and container capacity, all with no API key required.
- C.H. Robinson reported its generative-AI agents had performed over 3 million shipping tasks, and Nuvocargo launched a dozen agents handling more than 70% of load touchpoints. That is the kind of high-volume automation MCP is designed to standardise.
How to start safely
Exposing booking and payment actions to an autonomous agent raises the stakes, so build guardrails in from day one:
- Authenticate and scope. Issue the MCP server its own credentials (OAuth or scoped tokens), and grant each tool only the permissions it needs, so a tracking tool never holds booking rights.
- Keep a human in the loop for state changes. Quoting and tracking can run automatically, but anything that changes a booking or moves money should require explicit confirmation before the Tool executes.
- Make actions idempotent. Use client-supplied keys so a retried
book_loadcannot create duplicate shipments. - Respect rate limits and log everything. Agents can fire many calls quickly; throttle them and keep an audit trail of every tool invocation for dispute resolution and compliance.
Risks and limits
MCP is powerful but not magic. Agents can still hallucinate arguments, so validate every tool input against a strict schema and reject the implausible. Over-broad tool permissions are the main security risk, because a compromised or prompt-injected agent should never be able to move money or leak a customer's rate card. Treat an MCP server like any other public API surface: least privilege, input validation, monitoring, and confirmation gates on anything irreversible. For freight specifically, keep regulated flows (dangerous goods, customs) behind human review until you trust the agent's behaviour.
What this means for a freight marketplace
At GetTransport we run a marketplace where shippers compare carriers and book moves, and the MCP lens makes our roadmap concrete. The same operations a person performs in our interface map directly onto MCP tools: request quotes across multiple carriers, compare price against timing, book, then track. Reference data such as carrier coverage and lane pricing fits the Resource model instead. What I find most useful about a marketplace here is breadth. A single get_quote tool can fan out across many carriers at once, which is exactly the comparison an agent is good at orchestrating and a person finds tedious. The takeaway for shippers is that the booking workflow they already know is becoming something an assistant can drive end to end, as long as the platform exposes it through a clean, well-governed API. That last condition is where most of the real work lives, and it is the part I would not rush.
FAQ
What is MCP in logistics?
MCP, the Model Context Protocol, is an open standard that lets AI agents call logistics systems for quoting and booking freight, and for tracking it, through one integration that works across assistants such as Claude, ChatGPT, Copilot and Gemini.
How does an AI agent book freight with MCP?
The agent connects to an MCP server that exposes freight actions as tools; it calls a quote tool, then a booking tool, passing structured inputs that the server forwards to the underlying freight API.
Is MCP secure for freight booking?
It can be, if you scope each tool's permissions, authenticate the server, keep a human confirmation step on money-moving actions, validate every input and log all calls for audit.
Do I need a separate integration for each AI assistant?
No, that is the point of MCP. You build one server and it works with any MCP-compatible client, including Claude, ChatGPT, Microsoft Copilot, Gemini and Cursor.
What freight MCP servers already exist in 2026?
Production examples include Warp's warp-agent-mcp with 23 tools, CargoAi's CargoMART for air cargo, and the open FreightUtils server with 19 free logistics tools.


