The first time I read the Model Context Protocol specification I had a strong sense of déjà vu, and it took me a minute to place it.
I started my career building EDI systems and moving messages around for Motorola, DHL and the Lloyd's insurance market. I then spent the best part of two decades building Interlok at Adaptris, connecting airlines, banks, telcos and agribusinesses to their trading partners. What I was recognising was the pitch. A common message format. A way for each side to describe what it can do. Build one adapter and everyone can talk to you. We said exactly that about EDI, then XML, then SOA, then APIs.
In August I argued that cheap connection relocates the hard problems rather than removing them. MCP is the next test of that argument, and the stakes are higher, because the thing on the other end of the connection is now making decisions.
What MCP actually is
MCP is an open standard for letting AI applications discover and call external tools. A server wraps a system — a database, a SaaS product, your own API — and publishes a list of tools, each with a name, a description and an input schema. The host passes that list to a model, the model decides when a tool would help, and the host makes the call. The messages are JSON-RPC.
It has had a remarkable year. Anthropic gave it to the Linux Foundation's new Agentic AI Foundation in December 2025, so it is no longer one vendor's protocol. Every major assistant and IDE now speaks it. And in July the 2026-07-28 revision removed sessions entirely: every request now carries its own version and context, and any state is passed explicitly as a handle.
I confess that last change made me smile. An integration protocol has just rediscovered the self-describing, stateless message. An EDIFACT interchange header was doing that in 1987.
MCP is not an AI problem with some integration attached. It is an integration problem with a non-deterministic caller.
Five things we have already learned
The contract is the product. The EDIFACT standard was never enough on its own. An ORDERS message meant one thing to a retailer and something subtly different to its supplier, so every relationship came with an implementation guide that pinned down what each segment really meant. MCP has the same gap with a sharper edge: the tool description is the only documentation the model gets, and it reads it literally. gets customer data is the modern undocumented segment.
Onboarding is where the time goes. At Adaptris the technology was rarely what held a programme up. Getting the long tail of suppliers connected, tested and live was. Adding an MCP server looks like one line of configuration. In an enterprise it is a new trading partner: somebody has to vet it, decide what it may touch, give it credentials and test it against real data. Teams that treat it as a config change will discover the process the hard way.
Versions outlive everyone's intentions. There are EDI flows still running on directory versions from the nineties, because upgrading every partner at once is never worth the cost. MCP is barely two years old and already has two protocol eras that SDKs must support side by side. Plan on mixed versions for years, and version your own tool schemas deliberately rather than editing them in place.
Someone will ask you to prove what happened. We built signed receipts and message tracking because money and liability flowed through the messages. When an agent raises a purchase order or changes a credit limit through a tool, the same three questions arrive — who asked, what was sent, what came back — and they usually arrive from a CFO or an auditor. I wrote about what an auditor will actually accept earlier this year; none of it is optional because the caller is a model.
Failure handling is most of the work. The happy path is perhaps a fifth of any integration. The rest is retries, duplicates, partial failures and the dead-letter queue nobody watches. MCP has a sensible convention for errors — return something readable so the model can correct itself — but a model retrying is not the same as a system being idempotent. Anything that creates or changes a record needs to be safe to call twice.
What is genuinely new
If the analogy held completely this would be a short and slightly smug post. It does not, and the places it breaks are where the risk lives.
The caller is not deterministic. An EDI translator did exactly what its map said, every time. A model chooses which tool to call and with what arguments, based on a description and a conversation, and two identical requests can take different routes. Interface tests are necessary and nowhere near sufficient. You have to test behaviour: does the agent pick the right tool, and does it stop when it should?
Data can carry instructions. In thirty years of B2B messaging, the content of a message never told the translator what to do next. With MCP, a tool result goes straight back into the model's context, and text inside it can try to steer the model. A product description containing ignore your previous instructions is not a thought experiment. Every tool result, and every third-party tool description, has to be treated as untrusted input.
The menu is the interface. A trading partner sent you the documents you had agreed and nothing else. An agent sees every tool you expose, and each one costs context and adds a new way to be wrong. The instinct to wrap every API endpoint as a tool is the wrong one. A small number of well-described tools beats a complete one.
What I would actually do
- Write tool descriptions like implementation guides. What it does, when to use it, what each field means, and what it must never be used for.
- Run server onboarding as a process. Approval, least-privilege credentials, scoped tools, tests against real data. Read-only first; anything destructive gated behind a human.
- Log every tool call with the identity behind it. Request, response, who or what asked. Somewhere an auditor can query, not a log file that rolls in thirty days.
- Make writes idempotent and failures honest. Safe to call twice; partial success reported as partial success.
- Test the agent, not just the tools. Which tool it reaches for, with what arguments, and when it stops.
There is a fuller design-review checklist in the Integration Guys version of this piece.
Where I might be wrong
The models will get good enough that contracts matter less. Possibly. A sufficiently capable model can infer a great deal from a poor description. But inference is not agreement, and the moment money or liability is involved you want the meaning written down rather than guessed — by a human or a model.
This is just API governance with a new name. Largely true, and I would rather teams reused their API governance than invented something new. The two things it does not cover are the ones in the section above: a non-deterministic caller, and data that can issue instructions. Those need new controls, not renamed old ones.
It is too early to standardise any of this. The spec has changed a lot in two years and will change again. But contracts, onboarding, versioning, evidence and failure handling are not features of a particular revision. They survived EDIFACT, XML, SOAP and REST. I would bet on them surviving MCP.
The pattern, again
Every generation of integration technology makes connection cheaper, declares the problem solved, and then rediscovers semantics, delivery guarantees and evidence the expensive way. MCP is a genuinely good standard and I expect it to become the default way agents reach enterprise systems. That is exactly why the old discipline matters. The new EDI is going to need it.