MCP Spec 2026-07-28: What Changed From 2025-11-25

The Model Context Protocol (MCP) is versioned by date, and each revision ships with a changelog. This guide reads the changelog for revision 2026-07-28, which lists changes since revision 2025-11-25, and explains in plain terms what changed and why someone who only installs MCP servers may care. We read the page on 29 October 2026. It summarises a changelog, not the whole specification, and we did not test any server or client against the new revision. For the basics, start with What is MCP.

The big shifts

• No protocol-level sessions. The changelog says the Mcp-Session-Id header is gone from the Streamable HTTP transport and list endpoints no longer vary per connection. Servers that need state across calls use explicit handles passed as ordinary tool arguments.
• A stateless protocol. The initialize handshake was removed. Each request now states the protocol version and the client's capabilities in its own metadata, and a version mismatch returns an UnsupportedProtocolVersionError.
• Server discovery. Servers must implement a server/discover call to advertise the protocol versions they support, their capabilities and their identity.
• One subscription stream. A single subscriptions/listen stream replaces the old HTTP GET endpoint and the resource subscribe calls for change notifications.
• Multi round-trip requests. Instead of a server sending its own requests to a client, such as asking for user input, a server returns an input-required result and the client retries the original request with the answers.
• A result type on everything. Every result must now include a resultType field, set to complete or input_required.
• No resuming broken streams. SSE stream resumability was removed. If a response stream breaks, the request in progress is lost, and the client has to send it again as a fresh request with a new ID.
• Tasks became an extension. Experimental tasks moved out of the core protocol into an official extension.

Smaller changes worth knowing

• Caching hints. Results from the list calls for tools, prompts and resources now require ttlMs and cacheScope fields so clients can cache responses and poll less.
• Stable tool order. Servers should list tools in the same order every time, which helps client-side caching and prompt caching.
• Request headers. Streamable HTTP POST requests must carry standard Mcp-Method and Mcp-Name headers.
• Authorization tightening. Clients must validate an issuer parameter when an authorization server includes one, and saved client credentials are tied to the authorization server that issued them.
• Error code change. The resource-not-found error code changed from -32002 to -32602 to align with JSON-RPC.
• Tracing. Conventions for OpenTelemetry trace context in request metadata were documented.

What is now deprecated

The changelog says deprecated features stay in the specification for now but are slated for removal, and that new implementations should not adopt them. It lists four groups:

• The Roots, Sampling and Logging features. The suggested migrations are passing directories or files through tool parameters, resource URIs or server settings instead of Roots, direct use of LLM provider APIs instead of Sampling, and stderr output or OpenTelemetry instead of Logging.
• The HTTP+SSE transport, already deprecated as of protocol version 2025-03-26 and now formally reclassified as Deprecated. The replacement is Streamable HTTP.
• The includeContext values thisServer and allServers.
• OAuth 2.0 Dynamic Client Registration as a client registration mechanism, in favour of Client ID Metadata Documents, though it stays available for backwards compatibility.

The same revision adopts a feature lifecycle policy with three states, Active, Deprecated and Removed, and a minimum twelve-month deprecation window (the versioning page says at least ninety days under an expedited-removal exception), plus a registry of deprecated features. The registry gives the earliest removal for Roots, Sampling, Logging and Dynamic Client Registration as the first revision released on or after 2027-07-28, and for HTTP+SSE as three months after its deprecation proposal (SEP-2596) reaches Final. Earliest removal only makes a feature eligible for removal; the registry says the actual removal is a later decision.

What it means if you only use servers (our suggestions)

• Ask which revision a server and your client each support. A server written for an earlier revision may behave differently from one written for this one. The changelog adds that when an older server leaves out the result type, clients must read the result as complete, so some compatibility is built in, but it is not a guarantee for every feature.
• For remote servers, prefer Streamable HTTP over HTTP+SSE, since the older transport is deprecated.
• Do not build a workflow around Roots, Sampling or Logging. They still work today but are on the way out.
• Expect tool lists to be cacheable, and re-check them after a server update. Our guide on reading an MCP tool definition covers what to look at.
• Keep your permission and logging habits independent of the protocol version; the permission gating pattern applies either way.

What this is not

This is a reading of one changelog. It does not tell you whether a particular server or client has adopted the revision, and it is not an implementation guide. Check each project's own documentation, and browse our MCP server directory for the recorded details of each listed server. Accounts and planned features are not open yet; see what is planned.