This MCP revision
is a subtraction

Those earlier revisions followed a familiar path: establish how messages travel, then add mechanisms on top. The 2024-11-05 revision used HTTP+SSE as its transport, the layer that carries protocol messages over the network. SSE kept a long-lived HTTP connection open so that a server could continue pushing messages to a client. The largest change to that foundation came with 2025-03-26, when Streamable HTTP replaced HTTP+SSE and the older transport became deprecated.

The carrier changed, but the operating premise did not. A client connected and performed a handshake, an opening exchange in which both sides agreed on identity, protocol version and supported capabilities. In earlier MCP revisions, the client made initialize as its first call. The server could then assign a session marker that tied later requests together and allowed it to retain state shared across them. Each request depended on what had already been agreed.

That premise remained through the 2025-06-18 compatibility boundary and the previous 2025-11-25 revision. For clients using versions earlier than 2025-06-18, a server MAY treat a request without the version header as 2025-03-26. The sequence still belonged to the same protocol era: connect, establish shared context once, and rely on it afterward.

The specification gives the two eras its own names. Legacy covers protocol versions that establish a session with an initialize handshake, meaning 2025-11-25 and earlier. Modern covers protocol versions that convey version, identity, and capabilities as per-request metadata, meaning 2026-07-28 and later. Per-request metadata places the necessary context on every request instead of relying on an agreement made at connection time.

The dividing line is not a feature. It is whether the server has to remember what the client said before.

The official release description says 2026-07-28 moves MCP to a stateless core, while hardening authorization and graduating official extensions. The shift to a stateless core produces the longest chain of changes, and it is the through-line here.

A stateful server must remember information associated with a client across requests. Keeping that memory available can require a shared session store or stateful load balancing, where the load balancer repeatedly sends one client to the same server because that server still holds the relevant session state. A stateless server remembers nothing between requests because each request carries what it needs.

That makes an MCP server deployable as an ordinary HTTP workload. Requests can reach any available instance without first recovering shared session state or being pinned to the instance that handled the previous call. It also makes serverless deployment, where code runs for each request rather than remaining resident, a viable fit. The same applies at the edge, where a service runs across nodes closer to users and consecutive requests may land on different nodes.

The cost follows from removing the server's dependence on prior exchanges. Protocol-level sessions and the initialize handshake no longer anchor later calls. A stream can no longer rely on the protocol's previous resumability mechanism. More consequentially, the server loses the ability to initiate a request toward the client.

Several capabilities depended on that direction of travel. Sampling allowed a server to ask the client to run a model call on its behalf, avoiding the need for the server to hold model credentials. Roots allowed the server to ask which directories or files it could access. Elicitation allowed the server to pause execution while the client collected additional input from the user. These mechanisms made MCP more than an interface through which a client calls server methods.

For Sampling, the stated migration path is Integrate directly with LLM provider APIs. The model call therefore moves out of the client-mediated protocol flow, and each server making such calls must connect to a provider API and hold the required credentials itself.

The revision consequently changes both deployment and protocol scope. MCP becomes easier to operate across interchangeable HTTP instances because requests no longer depend on retained client state. At the same time, it narrows from a bidirectional protocol in which either side could initiate requests into a tool catalogue and a calling convention, with RPC methods such as tools/call defining what the client may invoke.

The document also formalizes how change will be managed. It introduces a feature lifecycle policy, a deprecation window of at least twelve months, a deprecation registry and a compatibility matrix spanning the Legacy and Modern eras. Deprecated features still exist and continue to work, but new implementations should not adopt them, and they become eligible for later removal under the specification's process. That leaves the concrete boundary of the new core to examine: what was removed, and what replaced it.

The official blog compresses the release into three moves: a stateless core, hardened authorization, and official extensions graduating into a versioned framework. The table below groups the nine major changes by what they do. The final row, the error-code renumbering, comes from "Minor changes" and is included because it determines which constants implementers have to update.

Previous MCP coverage on this site was about using it: what breaks in production, one DNS rebinding vulnerability in each of three official SDKs traced to the same default configuration, and the tool-token cost of wiring MCP into a Claude Code harness. This piece takes a different axis, which is where the protocol itself is going.

All of that is gone. The server exposes a single HTTP endpoint that accepts POST, and every JSON-RPC message from the client is its own POST. Protocol version, client identity and client capabilities are no longer settled by an opening handshake; they travel in each request's _meta field, and the server returns its own identity in each result's _meta. The spec is blunt about it: There is no negotiation handshake.

Every request now declares its own version and the server accepts or rejects each one independently. An unsupported version comes back as UnsupportedProtocolVersionError together with the list of versions the server does support, from which the client picks one and retries.

Statelessness is not free. Cross-call state that used to hang off the session has to become explicit data: the server mints a handle and passes it back as an ordinary tool argument for the client to carry into the next call. List endpoints can no longer vary their contents by connection either.

Server-initiated requests were not deprecated. They were changed outright. The MRTR page carries the spec's own label, This is a breaking change., and states that servers MUST use the new pattern because The previous pattern of server-initiated requests is no longer supported. The transport page marks the same thing as a behavioral change relative to 2025-03-26 through 2025-11-25, revisions in which servers could send their own JSON-RPC requests on SSE streams. This revision says MUST NOT.

Legacy traffic arriving at such a server has defined handling. A Last-Event-ID header is ignored, since streams are not resumable; an Mcp-Session-Id header is ignored too, and the server neither mints nor echoes session IDs.

With one response stream per request, cancellation semantics get cleaner. Closing that stream is itself the cancellation signal and the server MUST treat it as cancellation, a transport-level disconnect the spec calls unambiguous. This revision of the core protocol defines no client-to-server notifications over Streamable HTTP at all; notifications/cancelled survives only on stdio.

Long-running work leaves the core protocol for the official Tasks extension, identified as io.modelcontextprotocol/tasks (SEP-2663). The redesign swaps blocking for polling: tasks/result gives way to tasks/get, a new tasks/update carries client input mid-flight, and tasks/list is removed.

When a server judges that a request will run long, it answers with a CreateTaskResult identified by resultType: "task", carrying a taskId, an initial status, ttlMs and a suggested pollIntervalMs. The task is durably created before the response is sent, which makes the taskId a durable handle: a client that disconnects or restarts resumes polling with the same identifier.

Ordinary change notifications go through subscriptions/listen. The client opts in explicitly through a filter with four fields, toolsListChanged, promptsListChanged, resourcesListChanged and resourceSubscriptions. The server MUST NOT send types the client has not explicitly requested, and MUST send notifications/subscriptions/acknowledged as the first message, reflecting the subset it agreed to honor.

Every POST MUST carry MCP-Protocol-Version. Mcp-Method carries the method name on all requests; Mcp-Name carries params.name or params.uri on tools/call, resources/read and prompts/get. These headers are REQUIRED for compliance, not an optimization.

Tool parameters can be mirrored too. A server MAY annotate a parameter in a tool's inputSchema with x-mcp-header, and the client then mirrors that value into an Mcp-Param-{name} header. The spec's own example is a tool that executes SQL on Google Cloud Spanner, annotating its region parameter with x-mcp-header: "Region" so the request carries Mcp-Param-Region: us-west1.

Mirroring creates two copies of the same fact, so a server that processes the body MUST compare the mirrored headers against their corresponding body values. The stated reason is direct: to prevent different components in the network from relying on different sources of truth, such as a load balancer routing on the header value while the MCP server executes on the body value. An intermediary enforcing policy on mirrored headers, for instance routing or rate-limiting by tenant, SHOULD additionally verify that the version indicated by MCP-Protocol-Version requires header–body validation, and SHOULD reject the request rather than trust values it cannot confirm.

Under SEP-2549, results from five methods now carry two required cache fields: tools/list, prompts/list, resources/list, resources/read and resources/templates/list. Both complement the existing listChanged notifications rather than replacing them. Observability moves the same direction: trace conventions enter the spec while the Logging feature is deprecated, with stderr or OpenTelemetry as the migration path.

The change targets a relationship that is common in MCP and unusual elsewhere: This addresses the common MCP scenario where servers and clients have no pre-existing relationship. The client hosts its metadata at an HTTPS URL and that URL becomes the client_id. It MUST use the https scheme and contain a path component; the document MUST include at least client_id, client_name and redirect_uris; and the client_id value inside MUST match the document URL exactly.

Credentials keep a hard boundary. Under SEP-2352, clients using pre-registered credentials, or persisting credentials obtained through DCR, MUST bind them to the issuing server's issuer. When the authorization server changes, the client MUST NOT reuse credentials issued by a different server and MUST register again.

Two further repairs tighten issuer verification. Under SEP-2468, authorization servers SHOULD include the iss parameter specified by RFC 9207, and a client MUST validate a present iss against the recorded issuer before redeeming the authorization code. Under SEP-837, a client performing DCR MUST specify an appropriate application_type: omitting it yields the OIDC default of web, which can conflict with native-style redirect URIs, while desktop applications, mobile apps, CLI tools and locally hosted web applications reached through localhost SHOULD use native.

Currently deprecated features are collected in the registry. Roots, Sampling, Logging and Dynamic Client Registration all carry First revision released on or after 2027-07-28, meaning the earliest a removal could land is the first revision released on or after that date. The spec attaches a qualifier: The earliest removal marks when a feature becomes eligible for removal; the actual removal is a Core Maintainer decision taken during release preparation and may happen later.

The registry is a derived view; the per-feature deprecation notices and the changelog entries remain the normative records. Its Removed section is currently empty: No features have been removed under this policy yet.

The second policy piece is the compatibility matrix. The spec first sets out three generations: Modern for 2026-07-28 and later, carrying version, identity and capabilities as per-request metadata; Legacy for 2025-11-25 and earlier, establishing a session through an initialize handshake; and Dual-era for implementations supporting both. The matrix enumerates seven combinations, two of which fail.

The working bridge is a Dual-era server, which selects its behavior from how the client opens: a request carrying per-request _meta is handled statelessly, an initialize request follows legacy semantics, and the server MAY serve both generations concurrently on the same endpoint or within the same process.

Clients also have to probe which generation they are talking to. Era is a property of the server rather than of a single request, so clients SHOULD cache the result: for the lifetime of the server process on stdio, per origin on HTTP. An HTTP probe attempts a modern request first, and on 400 Bad Request the client SHOULD inspect the response body before falling back, because modern servers also use that status for an unsupported version, a missing required capability and header-validation failures; a recognized modern error in the body means the server is modern and the client should retry rather than downgrade. On stdio the probe is server/discover.

The process itself is pinned down too. SEP-1850 formalizes the SEP workflow, with proposals as markdown files in a seps/ directory, numbering derived from the PR, and status managed through PR labels.

MCP Apps let servers render interactive UI directly in the conversation, so users can see what a connector is doing and work with it inline without switching tabs. Enterprise-managed auth lets admins provision connectors for a whole organization through their identity provider: authorize once, users inherit access through existing IdP groups, and it is connected on first login, which the blog calls zero-touch setup for the end user. Observability for connector developers gives published connectors a dashboard for tracking adoption, diagnosing errors and latency, and breaking down usage by product. MCP tunnels, a research preview, connect Claude to MCP servers inside a private network with no inbound firewall rules, no public endpoints, and no IP allowlisting on the origin.

Claude lists over 950 MCP servers in the connectors directory, used by millions of people every day. Applied at that scale, each removal above means implementations across the ecosystem have to move with it.

Read together, the three point one way: MCP is narrowing its own definition to a tool catalog and a calling convention, and at the same time writing its boundaries and its pace into rules an engineering plan can rely on.