MCP Protocol Versions: Compatibility, Changes and Migration

Direct answer

MCP's current stable protocol revision is 2026-07-28, verified August 26, 2026. This guide compares the five principal post-launch revisions—2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, and 2026-07-28—without pretending that the list is the whole repository history. The official releases record also contains a pre-launch 2024-10-07 tag. It is acknowledged here, but kept outside the five-row comparison because this page follows the package's principal public-revision scope. [S054] [S313] [S336]

The decisive boundary is between the handshake era, which starts work with initialize and can depend on protocol sessions, and the modern era, which makes each request self-describing and removes protocol-level sessions. Compatibility is therefore not a yes-or-no MCP badge. It depends on the exact revision, lifecycle, transport, authorization profile, capabilities, extensions, SDK behavior, host policy, and topology. See MCP Apps. [S055] [S121] [S056]

A2A versions differ; see MCP vs A2A.

Jump to: versions, compatibility, testing.

---

MCP protocol versions at a glance

Table 1: MCP protocol versions at a glance comparison

Revision	Era	Lifecycle	Primary transports	Compatibility significance	Sources
2024-11-05	Handshake	initialize → initialize result → notifications/initialized	stdio; HTTP+SSE	Baseline launch-era behavior	[S249] [S026] [S027] [S028] [S029] [S030]
2025-03-26	Handshake	initialize handshake retained	stdio; Streamable HTTP; HTTP+SSE backward-compatibility	First remote-service-oriented revision	[S035] [S036] [S156] [S038] [S037]
2025-06-18	Handshake	initialize handshake retained	stdio; sessionful Streamable HTTP	Security hardening and rapid reversal of batching	[S042] [S043] [S159] [S320] [S044] [S046]
2025-11-25	Handshake	initialize handshake retained	stdio; sessionful Streamable HTTP	Last released handshake/session revision	[S048] [S049] [S160] [S321] [S187] [S050] [S336]
2026-07-28	Modern/stateless core	Optional server/discover; self-describing requests; no initialize	stdio; sessionless Streamable HTTP	Architectural era boundary	[S054] [S055] [S121] [S056] [S127] [S058] [S053] [S313] [S314]

The first row is the launch-era baseline used for this comparison, not a claim that no repository tag existed earlier. The separate 2024-10-07 tag is retained in the evidence record as pre-launch official release tag acknowledged outside the package five-row comparison matrix. [S336]

The table also separates deprecated from removed. A deprecated feature still exists during a migration window. A removed method or lifecycle step does not belong to the selected current revision, even if a dual-era implementation intentionally retains it for older clients.

---

What an MCP protocol version identifies

An MCP protocol version is an identifier for a particular revision of the protocol specification and schema. The identifier tells a client and server which message shapes, lifecycle rules, methods, result envelopes, transport requirements, capability semantics, and errors govern their interaction. The current versioning design uses a date string such as 2026-07-28. [S056]

This is conceptually different from the version of the software implementing the protocol. A Go SDK release can speak several MCP revisions. The official Go matrix, for example, states that SDK v1.7.0+ supports all five principal released revisions, while earlier Go SDK lines support smaller historical sets. [S325]

The same distinction applies to servers. A server package might publish version 3.4.1 while supporting MCP 2025-11-25 and 2026-07-28. The registry treats the package version as the publisher’s software-distribution identifier. It does not redefine the MCP protocol version. [S319]

Host products create a third version axis. “VS Code supports MCP” is a product claim, not a protocol revision. The product can add or restrict individual primitives, transports, authorization flows, extensions, confirmation interfaces, and compatibility behavior in different releases. The vendor may not publish one canonical MCP date for the product at all. [S140] [S141]

Extensions create a fourth axis. A host and server may share the 2026-07-28 core while disagreeing about MCP Apps, Tasks, or another extension. Core compatibility does not imply extension compatibility. [S137] [S318]

Protocol revision, SDK version, package version, and product version

Table 2: Protocol revision, SDK version, package version, and product version comparison

Versioned object	Example	What the value controls
MCP protocol	2026-07-28	Wire semantics between peers
SDK	Python 2.0.0, Go v1.7.0	Language API, implementation behavior, supported protocol set
MCP server package	1.4.2	One server implementation and its tools/resources/prompts
Host product	A particular VS Code, ChatGPT, or Claude release	Product UX, policy and implementation rollout
Extension	A Tasks or Apps extension release	Optional behavior outside the core revision
Release candidate	2026-07-28-RC	Testable pre-GA specification snapshot

Calling all of these “the MCP version” creates avoidable failures. A migration plan must identify every axis separately.

The practical rule is to record every version axis, rather than writing only “MCP version.”

Table 3: Protocol revision, SDK version, package version, and product version comparison

Versioned thing	Example	What it controls	Compatibility role	Sources
MCP protocol revision	2026-07-28	Wire semantics and normative behavior	Peers must share or bridge a protocol revision	[S056]
SDK software version	Go SDK v1.7.0; Python SDK 2.0.0	One language implementation/API	One SDK version may support several protocol revisions	[S322] [S324] [S325]
Server package version	1.4.2	One server implementation/distribution	May add tools or fixes without changing protocol revision	[S319]
Host product version	VS Code 1.xx; ChatGPT rollout date	User-facing product release	Determines which MCP features the product exposes	[S140] [S141]
Extension version	Tasks or Apps extension release	Optional protocol extension	Negotiated independently from core	[S137] [S318]
Release candidate	2026-07-28-RC	Pre-GA snapshot for testing	Not final; SDKs may implement at their own pace	[S053] [S314]
Informal label	MCP v2	Usually an era or SDK generation in secondary speech	Ambiguous; must be translated to an exact date/SDK version	[S056] [S252] [S322]

---

What changed in each principal revision

Read each revision as a frozen interoperability contract. A later revision can preserve a concept while changing its lifecycle, message shape, transport behavior, or authorization requirements.

2024-11-05: launch-era baseline

The original public specification described a stateful client-server protocol based on JSON-RPC 2.0. A host managed one or more clients; a client established a relationship with one server; the peers negotiated version and capabilities during initialization. Tools, resources, and prompts were already present. Client-side Sampling and Roots, protocol Logging, completion, progress, and resource subscriptions were also part of the early design. [S249] [S026] [S028] [S029] [S030]

Lifecycle

The client opened with initialize, identifying itself, proposing a protocol version, and advertising client capabilities. The server returned its selected version, identity, instructions, and server capabilities. The client then sent notifications/initialized. Only after that sequence could normal operation begin. [S026]

This lifecycle created a natural session concept. Capability support and identity could be stored once and reused throughout the relationship. Server-to-client requests—especially Sampling and Roots-related interaction—could travel over the established bidirectional channel.

Transports

The original standard transports were:

• stdio: the client spawned or connected to a process and exchanged newline-framed JSON-RPC over stdin and stdout.
• HTTP+SSE: the client opened a Server-Sent Events connection for server-to-client messages and used a server-supplied HTTP POST endpoint for client-to-server messages. [S027]

The network form was already possible at launch, but it was not the same as modern remote MCP. There was no current OAuth framework, no Streamable HTTP, no protected-resource metadata, no Resource Indicators, and no modern stateless request envelope.

Compatibility profile

A launch-era implementation should be evaluated against launch-era rules. It should not be condemned for omitting later OAuth or structured tool output, and it should not be described as supporting 2026 behavior merely because its methods have familiar names. The same tools/list label can exist in two revisions while surrounding lifecycle, result, caching, routing, and interaction semantics differ.

2025-03-26: remote infrastructure enters the core

The March 2025 revision was the first major attempt to make MCP more suitable for remote services. It retained the initialization and session model but changed the remote transport and added an authorization framework. [S035] [S036] [S156]

Streamable HTTP replaced the original network pattern

Streamable HTTP consolidated communication around an MCP endpoint that could return either ordinary JSON or an SSE stream. The design reduced dependence on the original two-endpoint HTTP+SSE arrangement. It still supported sessionful behavior, and the revision included backward-compatibility guidance for the previous transport. [S038]

This is why “MCP uses SSE” is historically imprecise. SSE was the defining server-to-client channel of the original HTTP+SSE transport. Under Streamable HTTP, SSE became an optional response mechanism within a different transport architecture. Under the 2026 revision, request-scoped SSE and selected subscription streams remain, while the protocol session and standalone GET stream do not. [S131]

OAuth framework

The March revision introduced a core authorization framework related to OAuth 2.1. This did not mean every local server needed OAuth, nor did it turn OAuth into an authentication guarantee. It defined roles and flows for protected remote resources, creating a common starting point that later revisions hardened. [S036] [S037]

JSON-RPC batching

Batching was added in March. That decision did not survive the next released revision. The brief lifespan is an important compatibility lesson: a feature can appear in an official release and still be reversed after implementation experience. [S036] [S043]

Tool annotations and other additions

The release added tool annotations describing characteristics such as read-only, destructive, idempotent, and open-world behavior. These are hints, not proofs. It also added audio content, progress-message text, and an explicit completions capability. [S036]

Compatibility profile

2025-03-26 is a handshake-era revision. A client supporting current Streamable HTTP but not legacy initialization is not automatically compatible with it. Likewise, a March implementation that emits JSON-RPC batches may be incompatible with a June-or-later implementation that correctly rejects batching.

2025-06-18: structured output and security hardening

The June revision kept the handshake/session lifecycle but made several consequential corrections and additions. [S042] [S043] [S159]

Batching was removed

JSON-RPC batching disappeared one release after it was added. Compatibility code cannot assume that “newer than launch” is enough to determine batching support. It must know the exact revision. A client emitting a batch because it connected to a generic “2025 MCP server” may be wrong for both pre-March and post-June peers. [S036] [S043]

Structured tool output

Tools gained outputSchema and structuredContent, making it possible for a server to return validated, machine-readable data alongside ordinary content. Resource links also became part of tool results. Older clients could still read text content, but hosts wishing to render tables, forms, or downstream automation needed explicit support for the new fields. [S043]

Elicitation

Elicitation allowed a server to request additional user information through the client. In the handshake era, this was a server-initiated request sent over the active protocol relationship. The current protocol preserves the user-interaction goal but changes the wire pattern to MRTR. [S046] [S126] [S317]

Authorization hardening

The revision classified MCP servers as OAuth resource servers, adopted protected-resource metadata, and used Resource Indicators to bind authorization to the intended resource. These changes addressed token-audience and confused-deputy risks. An implementation that merely accepted a bearer token was not therefore fully compatible with the hardened model. [S043] [S044]

Protocol-version HTTP header

The protocol version became material in HTTP transport metadata. This is the ancestor of the stronger current requirement that modern requests be self-describing. Hand-written clients and proxies that ignore version headers risk dispatching messages under the wrong schema. [S043] [S320]

2025-11-25: the final handshake-era release

The one-year revision expanded authorization discovery, metadata, elicitation, Sampling, and long-running-operation experiments without abandoning the initialization lifecycle. It is the last released revision in the handshake era. [S048] [S049] [S160]

Authorization and client identity

The release added or refined OpenID Connect discovery, Client ID Metadata Documents, incremental authorization scopes, and related metadata. These changes made remote client identification and authorization more interoperable but also more complex. A client and server can share the same core MCP revision and still fail because they implement different authorization discovery or registration assumptions. [S049] [S187]

Richer metadata and schemas

Icons, tool-name guidance, and a JSON Schema 2020-12 default improved discoverability and validation. Elicitation acquired richer schema behavior and URL-mode interaction. Sampling could incorporate tool use. [S049]

Experimental Tasks

Tasks entered as experimental core functionality for durable or long-running work. The experiment did not become the permanent core design unchanged. In 2026-07-28, Tasks moved to an official extension and the old task wire vocabulary became legacy compatibility material. [S050] [S137] [S168]

Why 2025-11-25 remains important

The current protocol does not instantly eliminate legacy deployments. SDKs and host products can continue to support the last handshake-era revision, and dual-era servers may need it for older clients. It is therefore a practical compatibility target, not merely a historical curiosity.

At the same time, describing its lifecycle as “current MCP” is wrong after July 2026. Documentation must label it by revision.

2026-07-28: the modern, stateless core

The July 2026 revision is the largest architectural change in the released protocol history. It removed the startup handshake and protocol session, moved peer identity and capabilities into request-scoped metadata, introduced server discovery, replaced server-originated requests, reorganized subscriptions, added HTTP routing and caching semantics, and formalized the relationship between the core and extensions. [S055] [S121] [S058]

No initialize

A modern client does not have to negotiate a connection before sending useful work. It can optionally ask server/discover which versions and capabilities the server advertises. It then sends self-describing requests that carry the selected version and relevant client metadata. [S056] [S127]

server/discover is not a renamed initialization session. It is an ordinary request that advertises information. It does not establish hidden connection state. A client that already has trusted, fresh discovery information may pin a known modern version instead of probing, depending on SDK support. [S127] [S166]

No protocol-level session

The current core removes Mcp-Session-Id. Any worker that can authenticate and authorize a request should be able to process it without retrieving an MCP session created by another worker. This aligns remote servers with ordinary horizontal scaling, load balancing, gateways, retries, and observability. [S055] [S061] [S316]

“Stateless protocol” does not mean “stateless application.” A server can maintain database records, authorization grants, Tasks, external jobs, caches, or durable workflow state. The difference is that later calls carry an explicit handle such as a task ID or draft ID rather than relying on an implicit MCP session. [S123]

Multi Round-Trip Requests

The modern core no longer provides the old server-to-client request channel. When a tool needs more user input, the server can return input_required with input requests and request state. The host gathers the response and retries the outer request. [S130] [S126] [S317]

This has several compatibility consequences:

• legacy elicitation callbacks are not the modern wire pattern;
• retries must avoid duplicate side effects;
• request state must be protected from tampering or cross-user reuse;
• hosts must preserve user consent across the retry;
• a client that understands ordinary tool results but not input_required is only partially compatible.

Header-based routing

Modern Streamable HTTP includes standard headers such as Mcp-Method and Mcp-Name, and selected tool parameters can be mirrored into Mcp-Param-* headers. Infrastructure can use them for routing and policy without fully parsing the JSON body, but implementations must validate header/body consistency and must not mirror secrets casually. [S055] [S131] [S168]

Cacheable results

Selected list and read results carry ttlMs and cacheScope. A client or intermediary cannot treat this as ordinary public HTTP caching without considering authorization context. The cache key must account for server identity, method, relevant parameters, user or tenant, scopes, protocol revision, and any other context affecting the result. [S055] [S123] [S124] [S168]

Subscriptions

Modern change delivery uses requested streams such as subscriptions/listen. The earlier pattern of opening a standalone session stream and sending unsolicited change notifications no longer describes the current HTTP core. Resource-specific resources/subscribe and resources/unsubscribe belong to the older model. [S055] [S124] [S323]

Extensions and Tasks

The core now has a formal extension framework. Tasks moved into an extension, allowing the long-running-work model to evolve without forcing every core implementation to adopt it. MCP Apps similarly require separate extension support. [S137] [S318]

Deprecations

Roots, Sampling, protocol Logging, HTTP+SSE, and Dynamic Client Registration are among the prominent deprecated surfaces. Deprecation starts a controlled migration; it is not instantaneous removal. The feature-lifecycle policy requires a minimum window and visible migration target, subject to defined governance exceptions. [S055] [S315] [S065]

---

Handshake era vs modern era

The official SDK ecosystem has increasingly adopted an era model because the lifecycle difference is larger than an ordinary feature flag. TypeScript and Python documentation explicitly distinguish the initialize generation from the modern generation. [S253] [S166]

Table 4: Handshake era vs modern era comparison

Axis	Handshake era (2024-11-05–2025-11-25)	Modern era (2026-07-28)
Opening exchange	initialize, result, notifications/initialized	Optional server/discover; no required handshake
Version selection	Negotiated once	Selected/discovered and declared per request
Client identity	Initialization-scoped	Request-scoped _meta
Capabilities	Negotiated once	Request-scoped, with discovery advertisement
Protocol session	Yes	No
HTTP session ID	Mcp-Session-Id in Streamable HTTP	Removed
Server→client requests	Supported over active relationship	Replaced by MRTR
Change notifications	Session/back-channel oriented	Requested subscription streams
Horizontal scaling	Often requires session affinity	Any authorized worker can process a request
Stateful workflow	Can hide state behind session	Uses explicit application handles
Cancellation over modern HTTP	Notification/session behavior	Close request SSE stream

The era model is useful, but it should not become a substitute for exact versions. All four handshake revisions are not identical: only March supported MCP batching; only June and later support structured tool output; authorization changes in each release. “Legacy” identifies a lifecycle family, not one uniform feature set.

Likewise, “modern” currently contains one released core revision. Future revisions could preserve the stateless lifecycle while changing other semantics. An implementation should still declare 2026-07-28, not merely “modern.”

A logical relationship is not a session

MCP still has clients and servers. A host can still create a client object that communicates with one logical server. A stdio process can remain open. An HTTP connection can be reused. None of those facts recreates a protocol-level session.

The distinction matters operationally:

• Logical client/server relationship: which capability provider the host is addressing.
• Transport connection: an OS pipe, HTTP connection, or other byte channel.
• Legacy protocol session: negotiated MCP state and, for Streamable HTTP, a session identifier.
• Application state: domain records, jobs, drafts, carts, queries, or task handles.

Only the third was removed from the modern core.

---

Version negotiation, discovery, and fallback

Before 2026, version selection occurred inside initialize: the client proposed a revision and the server returned the selected revision. In the modern era, a client can call server/discover, choose a shared revision, and send that revision plus client metadata with each request. A client that already has trusted, fresh information may pin a revision instead. [S056] [S127] [S026] [S160]

The important word is can. Modern clients differ in whether they probe automatically, pin, preserve a legacy default, or expose an explicit mode. A strict pin should fail when the server cannot speak that revision; silently falling back would defeat the policy the pin expresses. Cross-era fallback is an SDK feature, not an automatic property of MCP. [S253] [S168] [S166]

Current servers implement server/discover so a client can learn supported protocol revisions, identity, capabilities, and related information before sending another method. The call is useful but does not create a session. [S127]

There are three common client strategies.

11.1 Automatic discovery with legacy fallback

The client probes server/discover using a modern request. If the server responds, the client selects a supported modern revision. If the response indicates a legacy server, the client opens the older initialize lifecycle instead. Official Python and TypeScript SDKs document this pattern, though their defaults differ. [S253] [S166]

This is the most flexible strategy for general-purpose clients, but it has edge cases:

• a 401 response is authorization evidence, not protocol-era evidence;
• a proxy can return an HTML or generic error that should not be mistaken for “legacy”;
• an old stdio server may exit or hang when it receives an unknown pre-initialize request;
• probe timeouts can add latency;
• fallback must not silently lower security-sensitive requirements.

The TypeScript SDK describes a disposable sibling-process strategy for probing its own stdio transport so that an old server cannot consume or terminate the actual session process before initialization. That is an SDK implementation detail, not a requirement imposed on every language. [S253]

11.2 Version pinning

A client that already knows the server and supported revision can pin 2026-07-28. A strict pin should not fall back. If the server does not support the version, the connection or request fails clearly. [S253] [S166]

Pinning avoids a negotiation round trip but transfers responsibility to configuration or previously stored discovery data. A stale pin can break after a server rollback. A pin without prior discovery may also leave the client without server identity or capability metadata.

11.3 Cached discovery

A client can cache a DiscoverResult and reconnect with the selected version and prior metadata. This can remove repeated discovery traffic while preserving knowledge of the server. Cache freshness, server identity, authorization context, and revocation must be considered. The Python SDK documents a prior_discover pattern for this purpose. [S166]

Unsupported-version errors

Modern peers need deterministic behavior when the request names an unsupported protocol revision. An error should identify the mismatch and allow a client to choose another advertised version where policy permits. It should not execute the body under a guessed schema.

A gateway that accepts multiple versions should route by the declared protocol version before application handlers. This makes mixed-era deployments possible but also means the version header and body metadata are security-relevant dispatch inputs.

---

Client-server compatibility matrix

A modern client can use a legacy server only when it implements a legacy path and shares an older revision. A legacy client can use a current server only when the server preserves that path or a gateway translates it. One endpoint can serve both eras, but that convenience does not erase session affinity, process behavior, or topology differences. [S253] [S166] [S323] [S325] [S331]

Table 5: Client-server compatibility matrix comparison

Scenario	Expected path	Likely outcome	Failure to test	Sources
Modern client ↔ modern server	server/discover or pin; self-describing requests	Works if a shared 2026 revision, transport, auth and required capabilities exist	Unsupported version, missing capability, auth or extension mismatch	[S056] [S127] [S253] [S166]
Modern auto client ↔ legacy handshake server	server/discover probe fails or is classified as legacy; client falls back to initialize	Works if client implements fallback and shares an older revision	Probe timeout, stdio process behavior, no shared legacy version	[S253] [S166]
Modern pinned client ↔ legacy-only server	No legacy fallback	Fails by design	Era/version negotiation failure	[S253] [S168] [S166]
Legacy client ↔ dual-era server	initialize without modern version envelope; server routes to legacy transport	Works, often with session/sticky-routing cost	Server disabled legacy path, no shared revision, lost session routing	[S323]
Legacy client ↔ modern-only server	Client sends initialize; server rejects unsupported method/era	Fails unless a compatibility layer is present	Method not supported or no shared protocol version	[S253] [S168]
Same revision, required capability missing	Wire negotiation succeeds	Partial interoperability only	Host expects resources/prompts/elicitation/tasks not offered by server/client	[S121] [S127] [S073]
Same revision, transport mismatch	No connection	Fails before protocol exchange	Client supports stdio only while server is remote HTTP, or vice versa	[S057] [S132] [S131]
Same revision, authorization mismatch	HTTP/auth layer rejects or cannot complete discovery	Fails despite wire compatibility	Issuer, client registration, scopes, token audience or redirect behavior	[S133]
Core-compatible peers, extension mismatch	Core calls work; extension negotiation absent or rejected	Partial interoperability	Apps/Tasks extension unsupported by one side	[S137] [S318]
Modern client ↔ dual-era server over stdio	SDK-dependent probe strategy; some use disposable sibling process	Works when client protects the session child from a pre-initialize probe	Legacy server exits or hangs on unknown pre-initialize request	[S253]
Dual-era server behind multiple HTTP workers	Modern requests any worker; legacy sessions require stickiness unless stateless legacy mode	Mixed topology works with explicit routing policy	Legacy Mcp-Session-Id reaches wrong worker	[S323]
Same protocol version, host behavior differs	Both hosts connect	Different tool filtering, approval, context, errors and rendering	Assuming wire compatibility implies identical user experience	[S145] [S140] [S141] [S265] [S274]

“Likely outcome” is not a certification. Every row assumes that transport, authorization, required capabilities, and product policy also align.

---

Compatibility has multiple dimensions

A robust compatibility claim has at least seven layers.

12.1 Wire compatibility

Can both sides parse and produce the request, response, notification, result, and error shapes of the selected revision? A parser that accepts unknown fields may still fail on removed methods or required fields such as current result types.

12.2 Lifecycle compatibility

Does the client use initialize, modern discovery, a version pin, or an automatic strategy? Does the server support the same era? A current client configured as modern-only cannot use a server that knows only the handshake era.

12.3 Transport compatibility

A server available only over stdio is not reachable by a host that accepts only remote HTTPS. A host supporting Streamable HTTP may or may not preserve legacy SSE. Transport support must be listed separately from protocol version. [S057] [S090] [S274]

12.4 Authorization compatibility

The same wire revision can fail because the peers disagree about protected-resource metadata, issuer validation, client identification, redirect URIs, Resource Indicators, scopes, token audience, or enterprise-managed authorization. [S133]

12.5 Capability compatibility

Core MCP allows focused servers. A server may expose tools but not resources or prompts. A client may lack elicitation or subscriptions. An SDK tier measures broad implementation commitments, but a particular product can intentionally support less. [S121] [S073]

12.6 Extension compatibility

Tasks and MCP Apps are not guaranteed by 2026-07-28 core support. They require separately supported extension identifiers and semantics. [S137] [S318]

12.7 Host-behavior compatibility

Two hosts can connect to the same server and produce different behavior because they use different models, tool filtering, schema conversion, confirmation interfaces, context construction, authorization storage, result rendering, retry policy, and extension support.

This is why an interoperability report should say something like:

Server package 3.2.1 interoperated with Host X build 2026.8 over Streamable HTTP using MCP 2026-07-28, OAuth profile Y, tools/resources/prompts, modern subscriptions, and no extensions.

That statement is testable. “Works with MCP” is not.

Authorization compatibility

Table 6: Authorization compatibility comparison

Revision	Authorization state	Discovery or registration	Compatibility consequence	Sources
2024-11-05	No core authorization framework	Deployment-specific	Remote auth was implementation/transport-specific	[S249] [S026]
2025-03-26	OAuth 2.1-oriented framework introduced	Authorization-server discovery and dynamic registration concepts	Remote clients and servers gained normative auth responsibilities	[S036] [S037]
2025-06-18	Hardened resource-server model	Protected-resource metadata	Tokens minted for one server should not be replayed to another	[S043] [S044]
2025-11-25	Expanded discovery and consent	OIDC discovery; CIMD; richer client identification	Clients/servers can differ even when protocol core matches	[S049] [S187]
2026-07-28	Further issuer/client/credential hardening	CIMD preferred; DCR deprecated; enterprise extensions possible	Current conformance requires more than accepting bearer tokens	[S055] [S133]

Capability evolution

Table 7: Capability evolution comparison

Capability	2024-11-05	2025-06-18	2026-07-28	Current status	Sources
Tools	Active	Structured output/resource links	MRTR, caching, routing headers, explicit handles	Core active	[S249] [S035] [S042] [S048] [S054] [S055]
Resources	List/read/templates/direct subscribe	Resource links/content refinements	Cache fields; subscriptions/listen	Core active	[S249] [S035] [S042] [S048] [S054] [S055]
Prompts	List/get	Titles/content refinements	Cache/result envelope	Core active	[S249] [S035] [S042] [S048] [S054] [S055]
Sampling	Active server→client request	Active	Deprecated; MRTR/application model calls preferred	Deprecated	[S249] [S035] [S042] [S048] [S054] [S055]
Roots	Active client capability	Active	Deprecated	Deprecated	[S249] [S035] [S042] [S048] [S054] [S055]
Logging	Active protocol capability	Active	Deprecated; per-request logLevel path	Deprecated	[S249] [S035] [S042] [S048] [S054] [S055]
Elicitation	Absent	Introduced server→client request	MRTR/input_required	Core active in modern form	[S249] [S035] [S042] [S048] [S054] [S055]
Tasks	Absent	Absent	Official extension	Extension	[S249] [S035] [S042] [S048] [S054] [S055]

The focused MCP tools, resources, and prompts comparison explains why matching one primitive does not establish full capability compatibility. The MCP security guide covers the authorization and trust boundaries behind the version labels.

---

Transport compatibility

stdio survived every revision

stdio remains a standard transport from launch through the current specification. What changed is the protocol opening and message semantics carried over the pipes. A persistent process in 2026-07-28 is not a legacy MCP session merely because the byte channel remains open. [S132] [S027]

HTTP+SSE

The original remote transport used an SSE channel plus a server-provided POST endpoint. It was described as deprecated when Streamable HTTP replaced it in March 2025 and was brought under the formal lifecycle registry in July 2026. Hosts or frameworks that advertise “SSE support” may mean this legacy transport or modern request-scoped streaming; the wording must be qualified. [S027] [S036] [S055]

Sessionful Streamable HTTP

From March 2025 through November 2025, Streamable HTTP worked within the initialization/session architecture. The server could issue a session ID, maintain an optional standalone event stream, and send request-scoped SSE responses. [S038] [S320] [S321]

Modern Streamable HTTP

The current transport removes protocol sessions and the standalone GET event stream. A POST can return JSON or an SSE stream for that request. Cancellation can be signaled by closing the stream. Requested subscription streams carry selected events. [S131]

Compatibility matrix

Table 8: Compatibility matrix comparison

Client transport	Server transport	Result
stdio	local stdio	Possible if lifecycle/version also match
Streamable HTTP	modern Streamable HTTP	Possible with shared revision/auth
Legacy HTTP+SSE	modern-only Streamable HTTP	No direct compatibility
Modern Streamable HTTP client with legacy fallback	sessionful 2025 Streamable HTTP	Possible when SDK implements both eras
Remote-only host	local stdio server	Requires a bridge or local host integration

Transport is necessary but not sufficient. Matching HTTP endpoints do not guarantee matching protocol eras.

---

Breaking changes and deprecations

Protocol history is not a staircase in which every new feature remains forever. MCP’s most informative changes include reversals.

Batching: added, then removed

JSON-RPC batching entered in March and disappeared in June. This shows that an official release can contain a design the project later judges unsuitable. It also shows why date-frozen tests matter. [S036] [S043]

HTTP+SSE: launch transport, then legacy

The original network transport was superseded by Streamable HTTP within four months of public launch. It remained relevant for compatibility and product support but eventually became formally deprecated. [S027] [S036] [S055]

Sessions and initialization: foundational, then removed

The first four revisions made initialization central. The fifth removed it. A long-lived design can still be reversed when scale, routing, and infrastructure requirements change. [S026] [S160] [S055]

Server-originated requests: replaced rather than merely renamed

Legacy Sampling and elicitation depended on the server sending a request to the client over an established relationship. Modern MRTR puts the need for input into an outer result and relies on a retry. That changes error handling, cancellation, side-effect safety, and host control. [S046] [S317]

Tasks: core experiment to extension

Tasks did not disappear. Their governance and compatibility boundary changed. Moving them into an extension let the project evolve long-running work without tying every core implementation to the experimental wire model. [S050] [S137]

Why reversals belong in compatibility documentation

A developer reading only current documentation might never learn that:

• a March client can emit batches a June server rejects;
• a session header can be required by a 2025 server and invalid as a current-core assumption;
• a tool can return the same business result through two very different elicitation flows;
• a current SDK can retain old task types solely for interoperability.

Migration quality depends on preserving those abandoned paths in the historical record.

Current deprecated surfaces

Table 9: Current deprecated surfaces comparison

Current deprecated surface	Deprecated in	Migration direction	Earliest removal	Sources
Roots	2026-07-28	Pass scope through tool arguments, resource URIs, or server configuration	First revision released on or after 2027-07-28	[S055] [S315]
Sampling	2026-07-28	Invoke model-provider APIs directly where model access is required	First revision released on or after 2027-07-28	[S055] [S315]
Protocol Logging	2026-07-28	Use stderr for stdio and ordinary observability such as OpenTelemetry	First revision released on or after 2027-07-28	[S055] [S315]
Dynamic Client Registration	2026-07-28	Prefer Client ID Metadata Documents or managed registration	First revision released on or after 2027-07-28	[S055] [S133] [S315]
HTTP+SSE transport	2025-03-26; formally registered in 2026	Migrate to Streamable HTTP	Three months after SEP-2596 reached Final; removal still requires a maintainer decision	[S055] [S315]
Sampling includeContext values thisServer and allServers	2025-11-25	Omit the field or use none	Follows Sampling	[S055] [S315]

The table includes the Sampling includeContext deprecation. Tasks moved from the experimental core into an independently versioned extension. JSON-RPC batching was removed in 2025-06-18, before the formal deprecation policy existed. These changes need different migration work, so the table identifies them separately. [S137] [S036] [S043] [S050]

Removal eligibility is not an automatic deletion date. A deprecated surface can remain longer, and any current status must be rechecked against the official 2026-07-28 deprecated-features registry and changelog before publication or migration. [S055] [S315] [S065]

---

SDK and host compatibility

SDK SemVer does not determine the wire revision. One SDK release can speak several MCP revisions, and a major library upgrade can retain a legacy default. Tiers are governance classifications covering conformance, completeness, documentation, and maintenance; extensions are not required for a tier. [S073] [S253] [S322]

Official SDK snapshot

Table 10: Official SDK snapshot comparison

SDK	Official tier	Stable line	Highest documented protocol	Negotiation or compatibility note	Sources
TypeScript	Tier 1	v2 packages	2026-07-28	Available through versionNegotiation mode=auto; default hand-built client remains legacy unless opted in Exact package versions and defaults can change.	[S138] [S252] [S253] [S168] [S322]
Python	Tier 1	2.x	2026-07-28	Default auto probe, then initialize fallback Exact PyPI version must be checked at publication.	[S138] [S166] [S323] [S324]
C#	Tier 1	2.x/current official line	2026-07-28 per GA/Tier 1 readiness	SDK-specific; verify current docs Exact NuGet package-to-revision matrix requires live check.	[S058] [S138] [S078] [S327]
Go	Tier 1	v1.7.0+	2026-07-28	Current SDK supports modern and legacy negotiation/fallback Use the exact compatibility table for the deployed SDK version.	[S138] [S325] [S326]
Java	Tier 2	2.x	2025-11-25 in reviewed stable release documentation	2026 server/discover support not established in reviewed stable line Open implementation work may have landed after verification.	[S138] [S328] [S329]
Rust	Tier 1	rmcp 3.x	2026-07-28	SDK-specific modern/legacy behavior Official SDK documentation checked on 2026-08-26 lists Rust as Tier 1; crate versions and protocol behavior still require a live check.	[S138] [S330]
Ruby	Tier 2	1.x	2026-07-28	server/discover probe with initialize fallback Tier 1 assessment was pending; official page still listed Tier 2 at verification.	[S138] [S331] [S084] [S332]
Swift	Tier 3	Current repository release	Not established as complete for 2026-07-28	Not established Review release notes and conformance status before use.	[S138] [S082]
PHP	Tier 3	Current official line	Dual-era behavior documented, but tier audit indicates incomplete conformance	Documented in protocol-version guide Protocol documentation does not erase Tier 3 conformance limitations.	[S138] [S333] [S334]
Kotlin	Tier 3	Current repository release	Not established as complete for 2026-07-28	Not established Review open 2026 implementation work and current conformance.	[S138] [S080]

The official SDK page listed Rust as Tier 1 when checked on August 26, 2026. Earlier research listed Tier 2. Check the official page for current tiers and package versions. [S138] [S330]

Host disclosure snapshot

Table 11: Host disclosure snapshot comparison

Product	MCP role	Exact revision disclosed?	Transport or compatibility scope	Sources
Claude Desktop	Host containing clients	Not established in reviewed public product source	Local and remote support documented across Anthropic sources Product support can differ from protocol and SDK support	[S145]
Claude Code	Host/client; can also expose itself as a server	Not established in reviewed public page	Local and remote MCP documented Role varies by mode; exact wire revision must be tested	[S259]
ChatGPT developer mode	Host with remote MCP connector support	Not stated in reviewed help article	Remote connections; product-specific connector path A claim of MCP support does not establish every optional capability or revision	[S140]
OpenAI Agents SDK	Application framework/client manager	Not consistently stated in overview	Hosted MCP, Streamable HTTP, stdio, legacy SSE Framework mode and server transport affect behavior	[S090]
VS Code	Host/client	Not stated as one canonical date in reviewed product docs	Local stdio and remote HTTP Feature support can roll out independently of spec publication	[S141]
GitHub Copilot coding agent	Cloud host/client	Not stated	Product-configured remote/server integrations Capabilities restricted; not all resources/prompts/OAuth behavior available	[S265]
Cursor	Host/client	Not stated in reviewed product page	Local and remote server configuration Need product-level interoperability test	[S269]
Gemini CLI	Host/client	Not stated in reviewed overview	Local and remote integrations documented Feature support and revision should be verified through release notes/tests	[S144]
JetBrains AI Assistant	Host/client	Not stated as a date	stdio, Streamable HTTP, legacy SSE Transport list does not prove all protocol capabilities	[S274]
Zed	Host/client	Not stated in reviewed product source	Context server/MCP integration Use live product docs and interoperability tests	[S284]
MCP Inspector v2	Diagnostic client/host-like developer tool	Explicit legacy/modern protocol-era support	Multiple developer-test transports Inspector support is not evidence that another host supports the same feature	[S297]

Most reviewed host pages describe features and transports without committing to one canonical MCP date. “Not stated” does not mean unsupported; it means the exact revision should be established by vendor confirmation, release notes, or an interoperability test. The maintained host compatibility guide tracks product-specific evidence separately.

---

Migration from 2025-11-25 to 2026-07-28

Migration is an era change, not a search-and-replace exercise. Decide whether the product will be modern-only, modern-preferred with fallback, or dual-era for a stated sunset period, then test that policy explicitly.

Client migration

Add an explicit version strategy

Choose among:

• automatic discovery with fallback;
• strict modern pin;
• legacy-only mode;
• a policy-driven minimum version.

Do not let the SDK default make this architectural decision invisibly. TypeScript and Python use different defaults. [S253] [S166]

Implement modern request metadata

Every useful request must carry the current protocol version and relevant client identity/capabilities. Treat the metadata as part of the signed, authenticated, logged request context. [S056]

Parse current result types

A modern operation can return complete or input_required. The client must preserve request state, gather input, and retry safely. A generic JSON decoder that ignores the field can cause the host to treat an incomplete operation as finished. [S130] [S317]

Replace direct subscription methods

Move resource and list-change monitoring to subscriptions/listen. Ensure the client subscribes only to needed event classes and tears down the stream cleanly. [S124]

Implement caching conservatively

Do not cache merely because ttlMs is positive. Respect cacheScope, authorization, tenant, scopes, server identity, method, parameters, and protocol revision. Invalidate on explicit change events where applicable. [S123] [S124]

Update cancellation

For modern Streamable HTTP, cancel by closing the request’s SSE response stream. Continue legacy notification behavior only on the legacy path. [S131] [S168]

Keep legacy fallback tested

If legacy support is claimed, maintain explicit tests for initialization, session IDs, server-originated requests, standalone streams, and old result shapes. Do not assume modern tests cover them.

Server migration

Implement discovery

Return accurate supported versions, capabilities, instructions, and identity. Do not advertise a revision merely because the SDK can parse its types; the server’s handlers, transport, auth, caching, and extensions must actually conform. [S127]

Remove hidden session dependencies

Search for code that obtains user, tenant, authorization, feature flags, working directory, open transaction, or workflow state from an MCP session object. Move request-critical data into authenticated request context or explicit handles. [S061] [S316]

Build explicit state handles

A server that begins a build, report, research run, or draft should return an identifier. Later requests carry the identifier. The server validates ownership and scopes every time. Handles should not be predictable cross-tenant counters when they grant access to sensitive state. [S123]

Convert client callbacks to MRTR

Replace direct server-to-client Sampling or elicitation requests with an input-required result and retry. Design the handler so the first round does not create irreversible side effects before required consent is collected. [S317]

Publish cache policy

Return conservative cache hints. Use a zero TTL or private scope when output depends on rapidly changing authorization or data. Avoid shared caching for user-specific catalogs.

Implement modern subscriptions

Publish change events to requested subscription streams. If the same server supports legacy clients, invoke the appropriate legacy and modern event paths deliberately rather than hoping one notification reaches both. [S323]

Decide on legacy support

A dual-era server can maximize reach but adds code paths, tests, session routing, and security review. A modern-only server reduces complexity but requires controlled clients. Publish the decision.

Host and product migration

Hosts sit above SDK transport details but cannot ignore them.

Expose the negotiated revision

Support logs and user-facing diagnostics should show:

• server identity and endpoint;
• transport;
• SDK version;
• selected MCP protocol revision;
• legacy or modern era;
• capabilities and extensions;
• authorization profile;
• fallback or downgrade events.

Without this data, a user sees only “MCP error,” and maintainers cannot reproduce the environment.

Preserve permission semantics

When a legacy server sends elicitation/create and a modern server returns input_required, the user should receive equivalent information and control. The host should not weaken confirmation because the wire mechanism changed.

Distinguish failure layers

Show whether failure occurred in:

1. process startup or network transport;
2. OAuth or identity;
3. protocol version selection;
4. capability invocation;
5. extension negotiation;
6. application operation;
7. model/tool mediation.

Avoid false completeness claims

A host that supports remote tools is not automatically a complete MCP host. Resources, prompts, subscriptions, elicitation, Apps, Tasks, and legacy fallback need their own evidence.

The dedicated 2026-07-28 change guide and stateful-to-stateless migration guide provide implementation-level follow-through.

---

Compatibility testing checklist

Documentation narrows the test matrix; it cannot prove interoperability. Record the host build, SDK and server package versions, selected core revision, transport, authorization profile, capabilities, extensions, legacy policy, test date, and primary evidence.

A credible test suite must contain negative cases. Happy-path tools/list and tools/call prove little about version boundaries.

Version tests

• discover a modern server;
• fall back to a legacy server;
• pin against an incompatible server and fail;
• negotiate each claimed legacy revision;
• reject unsupported versions predictably;
• ensure a modern body without required HTTP metadata is rejected where specified.

State tests

• send sequential modern requests to different replicas;
• attempt to reuse another user’s state handle;
• test legacy session affinity across workers;
• restart a server between rounds of a workflow;
• repeat an MRTR retry and confirm idempotency.

Transport tests

• stdio server exits before initialization;
• malformed stdout logging;
• HTTP request-scoped stream interruption;
• modern cancellation by stream close;
• legacy session termination;
• proxy/header normalization.

Capability tests

• structured output validation;
• cache hints and authorization-separated cache keys;
• subscriptions for resource and list changes;
• elicitation accept, decline and cancel;
• unknown extension behavior;
• deprecated feature warnings.

Cross-host tests

Run the same server with two hosts. Compare the available tool catalog, names, prompts, resources, confirmations, auth, results, and errors. Interoperability does not require identical UI, but materially different behavior must be documented.

The package accompanying this article includes a complete test specification and machine-readable matrices.

The downloadable interoperability and breaking-change registers below are useful inputs, but production approval should retain packet-level or conformance evidence for the exact deployed combination.

---

Common versioning mistakes

“Our server supports MCP v2”

Rewrite as:

Server 3.2.1 supports MCP 2026-07-28 over stdio and Streamable HTTP, plus legacy 2025-11-25 over stdio. It supports tools, resources, prompts, and MRTR; Tasks extension is not supported.

“We upgraded the SDK, so we use the new protocol”

Not necessarily. SDK defaults can preserve older wire behavior. Check the negotiated revision at runtime. [S168]

“The new protocol is backward compatible”

Ask: through which SDK fallback, server dual-era path, transport, capabilities, and auth profile? Compatibility is implemented, not metaphysical.

“Deprecated features no longer work”

They remain present during the migration window. New code should avoid them, but a server claiming legacy or deprecated support must continue to test them. [S315]

“The host supports MCP, so the server will work”

The host may support only tools, only remote servers, only a particular authorization flow, or only one lifecycle era. Verify the product matrix.

“The latest documentation describes every deployed server”

Versioned documentation exists because old deployments remain. Use the documentation for the selected revision.

---

Frequently asked questions

---

Sources, downloads, and methodology

The comparison links each historical behavior to its specification revision. SDK and host support are dated observations; check the product documentation before relying on a particular version.

Show all 81 canonical evidence records used by the source article

S054 S056 S313 S336 S026 S156 S159 S160 S055 S127 S058 S253 S166 S323 S325 S331 S315 S317 S137 S050 S319 S140 S141 S318 S029 S124 S249 S335 S252 S168 S322 S053 S314 S028 S030 S027 S035 S036 S038 S131 S037 S043 S042 S046 S126 S044 S320 S048 S049 S187 S121 S061 S316 S123 S130 S065 S057 S090 S274 S133 S073 S132 S321 S125 S138 S078 S327 S328 S329 S330 S332 S333 S334 S082 S080 S145 S259 S269 S144 S284 S297

See the source library and editorial policy for references and review dates.