MCP and AI Interoperability — The Standardisation That Was Missing

Anthropic released Model Context Protocol (MCP) in late November 2024 as an attempted standard for connecting AI models to external context — tools, data sources, prompts. The technical details are interesting; the strategic significance is larger. For the first time in this generation of AI, a credible attempt at standardising the connection layer between models and the systems they reach into.

This is a brief practitioner view of what MCP is, why standardisation matters for enterprise architectures, and how to think about it without over-committing to an early standard.

What MCP is

MCP defines a protocol for AI applications (the client) to discover and use resources, tools, and prompts exposed by external services (the servers). The client connects to the server; the server advertises what it offers; the client uses what it needs.

The shape is similar to LSP (Language Server Protocol) — a successful standardisation in a related space. The intent is similar: any client that speaks the protocol can use any server that speaks the protocol, without bespoke integration for each pair.

What MCP servers can expose:

• Resources — data the model can read (files, database queries, web content)
• Tools — functions the model can call (API operations, computations)
• Prompts — templated prompts the application can use

The protocol handles discovery, capability negotiation, invocation, and result handling.

Why this matters for enterprise architecture

Before MCP, every AI application built its own integration layer for every system it needed to reach. The result is what enterprise integration looked like before standards like ODBC, JDBC, or REST emerged — every connection custom-built, no reuse, no portability.

A standard for AI-to-system connectivity offers:

• Reusability. An MCP server for SharePoint, Confluence, Salesforce, or an internal system can be built once and used by many AI applications.
• Portability. An AI application built against MCP can switch the underlying model (any MCP-aware model client) without rewriting connectors.
• Governance. A single integration surface to control, audit, and govern, rather than many.
• Ecosystem. Vendor MCP servers, community MCP servers, internal MCP servers — all interoperable.

This is the standardisation enterprise architects have been waiting for. It is also early — adoption is starting, the ecosystem is forming, real production deployments are nascent.

What to do about it in 2024-2025

A measured posture for enterprise teams:

Track the standard

Read the specification. Understand what it covers and what it doesn't. Form an opinion about whether it fits your architecture.

Build new connectors with MCP in mind

For new AI integration work, consider building MCP servers rather than bespoke integrations. The marginal cost is small; the option value is large.

Don't rewrite existing connectors yet

The standard is new. The implementations are early. Rewriting working bespoke integrations to MCP without a specific reason is over-investment. Wait for stable patterns.

Watch the ecosystem

The standard's value depends on adoption. Who builds servers? Who builds clients? Which vendors expose their systems as MCP servers? The answers will determine whether MCP becomes a real standard or a curiosity.

Plan for multi-protocol futures

Even if MCP succeeds, it won't be the only protocol. OpenAI, Google, and others may have their own. Enterprise architectures should plan for multi-protocol, not single-protocol.

Engage governance

If your organisation is going to expose internal systems as MCP servers, the security, audit, and access control patterns need to be designed deliberately. MCP doesn't solve these; it provides the protocol layer on top of them.

Where the limits sit

MCP doesn't solve everything:

• Authentication and authorisation are mostly out-of-scope. Each server handles its own.
• Data privacy and residency are not addressed by the protocol; they have to be enforced elsewhere.
• Performance characteristics vary by server. A protocol can't make a slow underlying system fast.
• Semantic interoperability — what the resources and tools mean — is still per-server. Two CRM systems exposing customer data via MCP may use entirely different schemas.

These are the same limitations any integration standard has. The standard is the connection layer; the substance still has to be designed at each end.

What we keep seeing

In the early adoption we have observed:

Internal teams are exploring. Many enterprise teams are building MCP servers for their own systems as a way to expose enterprise data to AI workloads in a more governed way.

Vendor support is uneven. Some vendors are publishing MCP servers; many are waiting to see if the standard takes hold.

The Claude Desktop integration drove visibility. The most visible early MCP usage is connecting Claude Desktop to local resources, which is a narrow use case but a useful proof point.

Enterprise security teams are cautious. New protocols introduce new attack surfaces. The security review of MCP deployments is non-trivial.

What we recommend

For enterprise teams in late 2024 and early 2025:

1. Read the MCP specification. Form your own opinion about its fit.
2. Consider MCP for new AI connectivity work. The marginal cost is small; the option value is large.
3. Don't rewrite working integrations without a specific reason. Wait for the standard to stabilise.
4. Plan multi-protocol architectures. MCP may succeed; it will not be the only protocol.
5. Engage security and governance partners. The standard's adoption requires their support.
6. Watch the ecosystem. The value depends on which vendors and which internal teams adopt.

MCP may become the standard enterprise architecture has needed for AI integration. It may not. Either way, the standardisation conversation is now serious, and that is itself a meaningful shift. The teams that engage thoughtfully position themselves well. The teams that ignore the standardisation conversation, regardless of which standard ultimately succeeds, find themselves with more custom integration than they need to maintain.