MCP and Agent Interoperability: The Standards Fight Deciding the Stack

The Model Context Protocol launched in November 2024 as one company's open-source experiment. By 2026 it had roughly 97 million monthly SDK downloads, over 9,400 public servers, native support from every major model provider, and a new home at the Linux Foundation. Standards fights decide who owns the integration layer, and this one was settled faster than almost anyone expected.

What MCP actually is, without the jargon

The Model Context Protocol is a standard way for an AI application to connect to external tools, data sources and services. Instead of writing a bespoke integration for every combination of model and system, both sides implement one protocol.

It is worth being precise about what it is not, because three adjacent concepts get conflated constantly.

Function calling is a model behaviour, meaning the model's ability to decide it needs a tool. Retrieval augmented generation is a technique for grounding answers in a knowledge base. MCP is neither. It is an interoperability layer that sits above existing APIs, uses function calling as the invocation mechanism, and can expose retrieval as one of its resources.

The problem it addresses is unglamorous and expensive. Enterprise AI projects fail on system access far more often than on model quality, and every custom connector adds cost, risk and maintenance.

The adoption numbers, with their caveats

Native support arrived from every major model provider, including Anthropic, OpenAI, Google DeepMind and Microsoft. That combination of open governance and universal vendor support is unusual and it is the reason the standards question resolved quickly.

Concrete deployments exist rather than just intentions. One large payments company deployed company-wide with all servers built in-house and reported substantial token reduction. One observability vendor reported that close to 20% of monthly interactive queries were being made by agents rather than people.

Why the Linux Foundation donation mattered

In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI.

That move addressed the objection every enterprise architect raises about a standard controlled by one vendor. A protocol whose direction can be changed unilaterally by a company you also buy from is not a standard, it is a product decision you have no vote in.

Vendor-neutral governance changes the risk calculation for a buyer materially. It also changed how the roadmap works. The 2026 roadmap, published in March by the lead maintainer, is organised around working groups and priority areas rather than release milestones, which is what community governance looks like in practice.

The four priority areas are transport scalability, agent communication, governance maturation and enterprise readiness. Those are the concerns of a project running in production, not one seeking adoption.

What the July 2026 specification changed

The most consequential technical change was a move to a stateless architecture, removing transport-session overhead and making MCP behave like an ordinary web workload: cacheable, routable and horizontally scalable.

The release also added support for long-running tasks and enterprise-managed identity. Both are unglamorous and both are prerequisites for anything running at scale inside a large organisation.

What is commercially at stake

Protocol control determines who owns the integration layer, and the integration layer is where switching costs live.

The row worth watching is the last. Companies whose business was building and maintaining connectors between systems now face a standard that commoditises exactly that work. Some will move up the stack into orchestration and governance. Others will not.

The row worth understanding if you are a software vendor is the second. Exposing your product through a standard protocol means every agent can reach it, which is distribution. It also means your integration depth stops being a differentiator, which was frequently the thing keeping customers from leaving.

The risks nobody has solved

Three, and they are all real rather than theoretical.

Supply chain exposure. Connecting an agent to a third-party tool server extends trust to code you did not review, running with permissions you granted. Adoption has outpaced vetting practice considerably, and there is no standard answer to who checks a server before it is connected.

The visibility gap. The most commonly cited enterprise concern in early 2026 was deploying agents without visibility into what they actually did. A protocol standardises the connection and does not, by itself, produce an audit trail anyone can read.

Tool overexposure. Connecting many servers gives an agent many capabilities and a context window full of tool definitions. That degrades performance and widens the blast radius of any single mistake.

These sit alongside the wider agent governance problem, examined in the analysis of where AI deployments actually succeed. Standardising the plumbing does not standardise the judgement about what the plumbing should be allowed to do.

Why the protocol cannot solve these

A standard defines how systems talk. It does not decide which systems should be allowed to talk, what they may do once connected, or who is accountable when something goes wrong.

Those are governance questions and they sit with the organisation deploying the agent. Treating protocol adoption as a security posture is the specific mistake to avoid here, and it is a common one because standardisation feels like control.

Be careful with the statistics in this category

This deserves its own section because the discipline is unusual and worth crediting.

At least one MCP adoption tracker publicly revised its own article in May 2026, removing claims it could not verify. Among the removed figures was a widely circulated statistic that 78% of enterprise AI teams used MCP in production, along with several named deployment counts.

That correction is more useful than most of the statistics it replaced. It tells you that adoption numbers in this category have been circulating without primary sources, and that at least some of the confident percentages you will encounter were assembled rather than measured.

The figures that survive verification are the ones in this post: SDK download counts, public server registries, the donation to the Linux Foundation, and named vendor deployments. The confident enterprise-penetration percentages generally do not.

What would actually settle this

Three observable things, none of which requires a view on whether AI works.

Direction of seat counts at large customers. If licensed user counts fall across an installed base while revenue holds, the repricing worked. If both fall together, it did not.

Whether consumption revenue grows faster than seat revenue declines. This is the arithmetic the whole strategy depends on and it is visible in segment reporting if you read it carefully.

Whether data migration volumes rise. The system of record argument holds only while moving is expensive. A visible increase in customers actually migrating would indicate the switching cost is falling.

None of these will be announced. All three appear in reported results, quarter by quarter, for anyone willing to track them.

Where this reading is weak

Three problems with the argument above.

Download counts measure developer curiosity, not production deployment. Ninety-seven million monthly SDK downloads is an enormous number and it includes automated builds, experimentation and abandoned projects. Nobody publishes a credible figure for production usage.

Server counts have the same issue. A public registry entry is a published server, not a used one, and the gap between the official count and unofficial directory listings suggests substantial duplication and abandonment.

And a settled standard is not the same as a settled market. Protocol adoption resolves how systems connect. It leaves entirely open who orchestrates agents, who governs their permissions and who captures the value, which are larger commercial questions than the transport format.

Frequently asked questions

Where to start this week

If you are considering connecting agents to systems, do one thing before you connect anything.

Write down who reviews a server before it is added, what permissions it receives, and where the record of its actions is kept. Three lines. If you cannot answer all three, you are not ready to connect the first one, and the protocol will not answer them for you.

Start read-only. Reporting, search and draft generation carry limited downside. Add write actions later, with human approval for anything that changes a record, sends a message or moves money.

That sequencing is the conservative recommendation from practitioners running this in production, and it is notably more cautious than most vendor guidance. The reason is simple: a read-only mistake produces a wrong answer, and a write mistake produces a wrong record that other systems then act on.

Related reading