Interoperability & Value

The value of a standard

Reusability

Build a server once, use it from any MCP host.

Decoupling

Servers evolve independently of hosts and models.

Ecosystem growth

A marketplace of interchangeable servers and clients.

Reduced vendor lock-in

Switching models or hosts does not mean rebuilding integrations.

Interoperability in practice

Any compliant host can talk to any compliant server, regardless of implementation language
Official SDKs in 10 languages (TypeScript, Python, C#, Go, Java, Rust, Swift, Ruby, PHP, Kotlin) implement the same wire protocol
Capability negotiation lets implementations of different ages cooperate: participants only use features both sides support
Protocol versions use a date-based string in YYYY-MM-DD format (the current revision is 2026-07-28), incremented only when a backwards-incompatible change is made

How versions and capabilities are negotiated

In the current revision (2026-07-28) MCP is stateless — there is no initialize handshake. Instead:

Every client request carries the protocol version, client info, and client capabilities as _meta metadata, and the server accepts or rejects each request independently
Servers advertise their supported versions and capabilities via the server/discover request
If the server does not support the requested version, it returns an UnsupportedProtocolVersionError (JSON-RPC code -32022) listing the versions it does support, and the client can retry with a mutually supported version
Clients and servers may support multiple protocol versions simultaneously

sequenceDiagram
participant C as Client
participant S as Server
C->>S: server/discover
S-->>C: supportedVersions + capabilities
C->>S: request (_meta: protocolVersion, capabilities)
alt Version supported
  S-->>C: result
else Version not supported
  S-->>C: UnsupportedProtocolVersionError (-32022, data.supported)
  C->>S: retry with a mutually supported version
end

Version negotiation (2026-07-28)

Value for different stakeholders

Stakeholder	Value
App developers	Instant access to a catalog of existing servers
Tool/API providers	Build one integration, reach every MCP-enabled app
Enterprises	Standardized governance and audit surface for AI-tool access
End users	Richer, more capable AI applications

Key exam points

Interoperability comes from standardizing the protocol, not the implementation
Capability negotiation is what keeps different versions/implementations compatible
Version strings are dates (YYYY-MM-DD), bumped only on backwards-incompatible changes
MCP is openly governed: Anthropic donated it to the Linux Foundation’s Agentic AI Foundation (AAIF) in December 2025, with contributions from multiple vendors

Check your knowledge

📝 Check your knowledge

1. What format do MCP protocol version identifiers use?

2. In the 2026-07-28 revision, how does a client communicate its protocol version and capabilities?

3. What happens when a server does not support the protocol version a request declares?

4. What is the primary source of MCP's interoperability?

5. What value does MCP offer a tool/API provider compared to building per-app plugins?