What MCP really is — the shipping container for AI agents

In 1956 a former trucking magnate named Malcom McLean loaded fifty-eight aluminum boxes onto a converted tanker called the Ideal X and changed the world economy. As Marc Levinson tells it in The Box, the shipping container did not win because it moved cargo faster. It won because it killed a cost. Before the container, every handoff between a factory, a truck, a crane, a ship, and a warehouse required custom labor and bespoke handling. After the container, every link in the chain agreed on one standard interface — the corner casting, the twist-lock, the fixed dimensions — and the cost of connecting any two links collapsed toward zero.

The Model Context Protocol is the shipping container for AI agents. And like the container, its real story is not speed. It is the economics of a standard.

What the Model Context Protocol actually is

MCP is an open standard, introduced by Anthropic in late 2024 and since adopted well beyond it, for how an AI model connects to the tools, data, and systems it needs to do work. It defines a common way for a model (the "client") to discover what a given system (the "server") can do, to call those capabilities, and to receive results — without either side knowing the other's internal details in advance.

Before a standard like this, every integration was bespoke. If you had M models and N systems you wanted them to reach — your CRM, your database, your ticketing tool, your file store — you were on the hook for something approaching M times N custom connectors, each written, tested, and maintained by hand. MCP turns that M times N tangle into M plus N: each system exposes one MCP server, each model speaks one MCP client, and anything can plug into anything. That is the container's corner casting, redrawn for software.

MCP vs tool calling

A fair question: models could already call tools. Why a protocol?

Tool calling is the capability — a model emitting a structured request to run a function. MCP is the standard for how that function is described, discovered, and reached across a boundary you do not own. Plain tool calling lives inside one application: you wire each tool in by hand, in that app's own format. MCP makes the tool portable. A system that ships an MCP server can be used by any MCP-aware model, and a model that speaks MCP can reach any MCP server, with no custom glue. It is the difference between a part that fits one machine and a part that fits every machine built to the standard.

MCP vs A2A

We wrote about A2A recently, and the two are easy to confuse. The simplest way to hold them apart: MCP connects an agent downward to its tools and data; A2A connects agents sideways to each other. MCP is how an agent reaches into a database or an API. A2A is how one agent asks another agent to do something. A serious system uses both — MCP inside each agent to reach its tools, A2A between agents to delegate work. They are complementary layers, not competitors.

The container also made smuggling easier

Here is the part the "what is MCP" explainers skip. The shipping container did not only speed up trade. It also transformed smuggling. Once cargo moved in sealed, standardized boxes that nobody opened at each handoff, customs lost the ability to see inside. The very thing that made connection cheap — the opaque, standard box — made inspection hard.

MCP has the same shadow. A standard, easy connection between a model and your systems is also a standard, easy path for things to go wrong: a prompt-injection attack that tricks a model into calling a tool it should not, an over-scoped MCP server that hands an agent far more access than the task requires, a connector that quietly exposes data across a trust boundary. The protocol makes the pipe. It says nothing about who is allowed to send what through it, or how you would ever reconstruct what happened.

A standard connection is not standard trust

This is why we keep returning to the same point. A protocol solves connectivity. It does not, on its own, solve identity, approvals, cost control, guardrails, or tracing. Those live in the operating layer that wraps the agents — and once MCP makes it trivial for a model to reach into everything you run, that layer matters more, not less.

Concretely, the questions MCP does not answer for you:

• Identity and scope. Which agent is allowed to reach which server, with what permissions, on whose behalf?
• Approvals. When a tool call would send money, change a record, or email a customer, who signs off — and under what rules?
• Cost. What did this chain of tool calls cost, and what stops a runaway loop from spending without limit?
• Trace. Can you reconstruct, after the fact, exactly which tools were called, with what inputs, and why?

MCP is genuinely good news. It is the corner casting that lets enterprise AI stop paying the M times N integration tax. But the lesson of the container holds: the standard that makes connection cheap is the same standard that makes oversight your explicit job. Build the trust layer on purpose, because the protocol will not build it for you.

Conclusion

MCP is doing for AI what the container did for freight: turning a mess of bespoke, hand-built connections into one cheap standard interface. That is a real unlock, and if you are building agents you should adopt it. But do not mistake a standard connection for a standard of trust. The box moves the cargo; it does not decide what belongs in the box, or let you see inside once it is sealed. That decision — identity, approvals, cost, audit — stays with you, and it is exactly the layer we build.

References

• Levinson, M. (2016). The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger (2nd ed.). Princeton University Press.
• Anthropic (2024). Introducing the Model Context Protocol.
• Linux Foundation (2025). The Agent2Agent (A2A) Protocol Project.

---

Adopting MCP and wondering where identity, approvals, and cost control should live? Book a 30-minute call and we'll map it with you.