Integration Guys Ltd

We have been here before

The Model Context Protocol is solving a problem the integration world solved 40 years ago, and most of the hard lessons carry straight over.

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, an integration platform that connected airlines, banks, telcos and agribusinesses to their trading partners. So when I first read the MCP spec, I had a strong sense of déjà vu.

A common message format. A way for each side to describe what it can do. A promise that you build one adapter and everyone can talk to you. That pitch is word for word what we said about EDI, then XML, then SOA, then APIs.

That is not a criticism. MCP is a genuinely useful standard and it is moving fast. But the teams that will get the most from it are the ones who recognise it for what it is: an integration problem. And integration problems have a long, well-documented history of the same mistakes being made twice.

MCP in two minutes

MCP is an open standard that lets AI applications discover and call external tools and data through one interface, instead of a bespoke integration for every pairing.

An MCP server wraps a system (a database, a SaaS product, your own API) and publishes a list of tools. Each tool has a name, a description and a JSON Schema for its inputs. The AI application passes that list to the model, the model decides when a tool would help, and the application makes the call. Messages are JSON-RPC 2.0, carried over stdio locally or HTTP remotely.

Three things have happened in the last year that matter to anyone making architecture decisions:

• It has a neutral home. In December 2025 Anthropic donated MCP to the Linux Foundation's new Agentic AI Foundation, alongside OpenAI's AGENTS.md and Block's goose. It is no longer one vendor's protocol.
• It is everywhere. Claude, ChatGPT, Copilot, VS Code, Cursor and Gemini all speak it, and there are well over 10,000 public servers.
• It just grew up. The 2026-07-28 revision, the biggest since launch, made the protocol stateless. The handshake and sessions are gone; every request now carries its own version and context, and any state is passed explicitly as a handle.

That last change is the one that made me smile. An integration protocol has just rediscovered the self-describing, stateless message. EDI got there in the 1980s.

Five lessons B2B integration already learned

1. The contract is the product

In EDI, the standard was never enough. An 850 purchase order 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 field really meant.

MCP has the same gap, with a twist: the reader of your contract is a model. Your tool description is the only documentation it gets, and it will act on it literally. A vague description such as "gets customer data" is the modern equivalent of an undocumented segment. Write descriptions the way you would write an implementation guide: what the tool does, when to use it, what each field means, and what it will not do.

2. Onboarding is where projects stall

With Adaptris customers, the technology was rarely the bottleneck. Getting the 200th supplier connected, tested and live was. Partner onboarding consumed more effort than building the hub.

MCP looks easy because adding a server is one line of config. But in an enterprise, every server is a new trading partner: someone has to vet it, grant it credentials, decide which tools it may expose and test it against real data. Budget for onboarding as a process, not a config change.

3. Versions live for decades

There are still EDI flows running on directory versions from the 1990s, because the cost of upgrading every partner at once is never worth it. Hubs survive by speaking several versions at once.

MCP versions its spec by date, and the 2026-07-28 revision broke enough that SDKs now support both the old session-based era and the new stateless one. Expect to run mixed versions for years. Design your servers to negotiate, and version your own tool schemas deliberately rather than changing them in place.

4. You will be asked to prove what happened

B2B messaging invested heavily in non-repudiation: signed receipts, message tracking, audit trails that would stand up in a dispute. Nobody did that for fun. They did it because money and liability flowed through those messages.

When an agent raises a purchase order or changes a credit limit through an MCP tool, the same question arrives: who asked for this, what exactly was sent, and what came back? If you cannot answer that from your logs, your auditors, regulators or CFO will not sign off (we covered the CFO side in The Black Box Problem). Log every tool call with the request, the identity behind it and the result.

5. Failure handling is most of the work

Any integration engineer will tell you the happy path is 20% of the effort. The rest is retries, duplicates, partial failures, poison messages and the dead-letter queue nobody monitors.

MCP gives you a sensible starting point: a failed call should return a readable error so the model can correct itself and try again. But a model retrying is not the same as a system being idempotent. If a tool creates something, make it safe to call twice. If it can partially succeed, say so in the result.

Where the analogy breaks

The analogy holds for the plumbing, but three things about MCP are genuinely new, and they are where the risk sits.

The caller is not deterministic. An EDI translator does exactly what its map says, every time. A model chooses which tool to call, and with which arguments, based on a description and a conversation. Two identical requests can take different paths. That means testing has to cover behaviour, not just the interface: does the agent pick the right tool, and does it stop when it should?

Data can carry instructions. In EDI, the content of a message never told the translator what to do next. With MCP, a tool result goes back into the model's context, and text inside it can try to steer the model. A supplier's product description that says "ignore previous instructions" is a real attack, not a hypothetical one (more in When AI Becomes a Weapon). Treat every tool result, and every third-party tool description, as untrusted input.

The menu is the interface. A trading partner only sent you the documents you agreed. An agent sees every tool you expose, and each one costs context and adds a way to go wrong. Some clients already cap the number of tools per request. A small, well-described set of tools beats one tool per API endpoint, every time.

A checklist before you put MCP into production

If you are deploying MCP servers in an enterprise, these are the questions I would ask in a design review:

• Contract: Is every tool description written for a literal-minded reader, with what it does, when to use it and what it must not be used for?
• Scope: Have we exposed the smallest useful set of tools, with read-only ones first and destructive ones gated?
• Onboarding: Is there a process for approving a new server, granting least-privilege credentials and testing it against real data?
• Versioning: Does the server support the 2026-07-28 revision and, where needed, older clients? Are our own tool schemas versioned?
• Audit: Do we log every tool call with the identity behind it, the request and the result, somewhere an auditor can query?
• Idempotency: Can every tool that creates or changes something be safely called twice?
• Errors: Do failures come back as readable results the model can act on, and do partial failures say so?
• Untrusted input: Are tool results and third-party descriptions treated as data, never instructions? Is there a human confirmation step for anything that moves money or changes records?
• Behavioural tests: Do we test which tools the agent chooses, not just whether each tool works?

The new EDI needs old discipline

MCP will become the default way AI agents reach enterprise systems, and that is a good thing. But it is integration, and integration rewards discipline over enthusiasm.

The organisations that did well with EDI, and later with APIs, were not the ones with the cleverest technology. They were the ones that treated contracts, onboarding, versioning, audit and failure handling as first-class work. The same will be true of agents.

If you are connecting AI agents to systems that matter (finance, supply chain, anything regulated) and want a second pair of eyes from someone who has made these mistakes before, get in touch.

Next week: can an LLM write your EDI maps? I put one to the test.

Sources

• What is MCP? The Model Context Protocol Explained (Scalar, September 2026)
• MCP 2026-07-28 specification release (GitHub)
• The Linux Foundation launches the Agentic AI Foundation (WorkOS)
• Linux Foundation launches Agentic AI Foundation (eeNews Europe)