MCP and the Interoperable Agent Stack

Every wave of enterprise automation has ended with a lock-in tax. The first ERP era, the first workflow suites, the first RPA generation — each promised composability and delivered a decade of expensive migrations. Agentic AI is on track to repeat the pattern, unless the interoperability layer becomes real fast enough that it does not.

Model Context Protocol is the most credible candidate we have seen for that layer. It is not the flashiest topic in AI, and it does not feature in most vendor pitches. It may end up being the most consequential architectural decision an enterprise makes about its agent stack this year.

The problem MCP solves is prosaic. Agents need to call tools — a CRM, a database, an internal API, a document store, a scheduling system. Every agent framework has its own way of describing those tools, its own way of authenticating to them, its own way of surfacing results back into the model's context. As a result, integrating the same tool with three different agent frameworks is three different pieces of work, done by three different teams, with three different failure modes.

MCP proposes a common protocol between the agent (client) and the tool (server). A single tool implementation exposes an MCP server; any MCP-compatible agent can call it. The tool describes its capabilities in a standard schema; the agent discovers and invokes them through the same mechanism regardless of the underlying model or framework. In principle, this is what USB-C did for physical connectors — an unglamorous standard that ended a decade of proprietary chaos.

For enterprises, three things matter about this.

The first is that the integration cost of a new tool becomes bounded. Today, connecting an internal CRM to your agent estate is a bespoke integration per agent platform. Under MCP, it is one server implementation that every current and future agent platform can consume. When you switch orchestration frameworks — and you will, at least once — the tool integrations survive the transition. That is the single largest source of lock-in in the current stack, and MCP substantially removes it.

The second is that the security surface becomes reviewable. An MCP server is a well-defined thing: a set of tools, a set of resources, a set of prompts, an authentication boundary. Your security team can review, approve, and monitor it as a single artifact. Compare that to the current state, where every agent framework calls tools through its own idiosyncratic mechanism, and the security review has to be redone every time the framework is updated. Governance overhead falls dramatically when the surface is standard.

The third is that the vendor conversation changes. When your tools speak MCP, the choice of foundation model, agent framework, or orchestration layer becomes a decision you can revisit annually without rebuilding the integration estate. That is the position enterprises should want to be in. It is not the position most vendors want their customers to be in, which tells you something useful about how to read the current market.

Some practical guidance for enterprises evaluating this now. Treat MCP as an architectural principle, not a product decision. Any new tool integration should be built as an MCP server by default, even if your current agent framework has a proprietary connector for it — the extra effort is modest, and the option value is significant. Existing integrations can be migrated opportunistically, when the underlying tool changes or the connector needs work anyway.

For the servers themselves, some early patterns are already stabilising. Keep servers small and focused — one tool domain per server (CRM, ticketing, knowledge base) rather than one giant server for everything. Enforce authentication at the server boundary, not inside individual tool handlers. Log every invocation, with the calling identity and the parameters, into the same observability stack you use for the rest of the agent estate. These sound obvious; they are also the places where the first generation of MCP servers has consistently gotten it wrong.

The failure modes to plan for are also predictable. Servers that expose too much (a whole database connection, rather than the specific queries the agent needs). Servers that leak error details in ways that help attackers infer schema. Servers that do not rate-limit and can be turned into a denial-of-service vector by a runaway agent. Standard secure-coding practice applies, but the review lens is slightly different because the client is a model, not a human.

The protocol is still young and it will change. That is fine. What matters for enterprise architecture decisions this year is not the exact version of the specification — it is the direction of travel. Interoperable, model-agnostic, framework-agnostic tool integration is where the industry is going. Enterprises that build for that direction now will move faster in two years than enterprises that keep writing framework-specific connectors.

There is a broader point about standards. Enterprises rarely benefit from being early adopters of unstable protocols, but they benefit enormously from being early adopters of protocols that are on their way to becoming standard. Reading which is which is a strategy skill, not a technology one. On the current evidence — provider adoption, ecosystem momentum, community engagement — MCP is on the second trajectory. That is worth positioning for now, quietly, in your architecture principles.