This article is part of our MCP Guide: what the Model Context Protocol is, how to use it safely, and how to choose servers, tools and help. Want a second opinion on your setup? Request a free MCP readiness review.
The 2026-07-28 version of the Model Context Protocol (MCP) specification, released on 28 July 2026, changed MCP from a stateful, session-based protocol into a stateless request-and-response protocol. Every request now carries the information a server needs, so servers no longer have to remember each client between calls.
The release also moved Tasks out of the core spec into an optional extension, added caching hints, tightened sign-in security, and deprecated several older features. It was the first spec release since 2025-11-25.
This guide lists only the changes shown in the official 2026-07-28 changelog and the release announcement on the MCP blog. We explain each one in plain English and say who it affects.
Key Takeaways
- MCP 2026-07-28 removed protocol-level sessions and the startup handshake, so any request can go to any server instance.
- A new
server/discovercall lets clients ask a server what it supports before sending other requests. - Tasks, for long-running jobs, moved from the core protocol into the official
io.modelcontextprotocol/tasksextension. - Roots, Sampling and Logging were deprecated, with a minimum twelve-month window before removal.
- Sign-in security was tightened, and Dynamic Client Registration was deprecated in favor of Client ID Metadata Documents.
- Most business users will not notice the change directly, but server owners and IT teams need a migration plan.
The big idea: MCP is now stateless
Before this release, an MCP client and server started with a handshake called initialize. The server then tracked a session ID for that client. Every later request depended on that session.
The 2026-07-28 release removed both. The MCP blog describes the change this way: "MCP is transforming from a bidirectional stateful protocol into a request/response stateless protocol."
Why it matters
The blog says the change answers developer demand for better reliability and scalability. With no session to track, "any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage."
For a business, that means remote MCP servers are simpler and cheaper to scale. It also makes them easier to put behind standard web infrastructure like load balancers, gateways and firewalls.
Stateless does not mean your app cannot remember things. The blog notes that "dropping the protocol-level session doesn't force your application to be stateless." Servers that need state now pass an explicit handle, such as an ID, as a normal tool argument.
Major changes, explained
The changelog lists nine major changes. Here they are, grouped by what they affect.
Sessions and startup
- Sessions removed. The
Mcp-Session-Idheader is gone from the Streamable HTTP transport. Tool, resource and prompt lists no longer vary per connection. - Handshake removed. There is no more
initializestep. Each request now carries its protocol version and client capabilities in a metadata field called_meta. - New
server/discovercall. Servers must implement it to advertise their supported versions, capabilities and identity. Clients may call it first, but it is optional. - Version errors. If client and server versions do not match, the server returns an
UnsupportedProtocolVersionError.
Notifications and housekeeping
- One stream for change alerts. A new
subscriptions/listenmethod replaces the old HTTP GET endpoint and resource subscribe and unsubscribe calls. Clients opt in to the specific alerts they want, such as "the tool list changed." - Removed methods.
ping,logging/setLevelandnotifications/roots/list_changedwere removed. Log level is now set per request. - No stream resumability. If a response stream breaks, the client must send the request again with a new ID.
Asking the user for more information
- Multi Round-Trip Requests (MRTR). Previously, a server could send its own requests back to the client mid-call, for example to ask the user a question. Now the server returns a result marked
input_requiredwith the questions it needs answered. The client then retries the original request with the answers. - Every result has a type. All results now carry a
resultTypefield, set tocompleteorinput_required.
Tasks moved to an extension
Tasks let a server hand back a ticket for a long job instead of making the client wait. The Tasks extension docs cover how it works now. In 2026-07-28, Tasks moved out of the core spec into an official extension. The redesign uses polling through tasks/get, adds tasks/update for sending input mid-task, and removes tasks/list. Our guide to MCP Apps, Tasks and Skills explains extensions in full.
Minor changes worth knowing
The changelog lists twelve minor changes. These are the ones most relevant to business and IT readers.
| Change | What it means in practice |
|---|---|
Official extensions field in capabilities | Clients and servers can formally agree on optional extensions like MCP Apps |
OpenTelemetry trace context in _meta | Easier to trace a request across systems with standard monitoring tools |
| Deterministic tool order | Servers should return tools in the same order, which helps caching |
Required Mcp-Method and Mcp-Name headers | Gateways can route and authorize requests without reading the message body |
ttlMs and cacheScope on list results | Clients can cache tool and resource lists instead of asking again and again |
iss validation in sign-in | Clients must check which authorization server issued a code before using it |
application_type in client registration | Avoids redirect conflicts for desktop and command-line apps |
| Credentials bound to their issuer | Clients must not reuse credentials with a different authorization server |
| Broader JSON Schema support | Tool input and output schemas can use any JSON Schema 2020-12 keyword |
The header and caching changes are good news for anyone running an MCP gateway. The sign-in changes matter if you run your own OAuth setup, which we cover in MCP authentication and OAuth 2.1.
The changelog also renumbers some error codes and reserves the range -32020 to -32099 for the MCP spec. That matters to developers, not end users.
What was deprecated
"Deprecated" means a feature still works but is scheduled for removal. New projects should not adopt it. The changelog lists four deprecations:
- Roots, Sampling and Logging. Suggested replacements: pass files or folders as tool parameters instead of Roots, call AI model APIs directly instead of Sampling, and log to
stderror OpenTelemetry instead of Logging. - The old HTTP+SSE transport. It was already deprecated in 2025-03-26. It is now formally classed as deprecated. Move to Streamable HTTP.
- Two
includeContextvalues. The valuesthisServerandallServersare deprecated. Omit the field or usenone. - Dynamic Client Registration (DCR). DCR is deprecated as a way for clients to register with an authorization server. The preferred method is now Client ID Metadata Documents. DCR remains available for older authorization servers.
The new deprecation policy
This release also adopted a formal feature lifecycle and deprecation policy. Features move through Active, Deprecated and Removed states. The minimum deprecation window is twelve months, with a shorter path only for active security risks. That gives teams a predictable runway to migrate.
Who needs to act
| You are... | What to do |
|---|---|
| A business user of Claude, ChatGPT or Copilot | Usually nothing. Your AI app and server vendors handle the update. |
| An IT or security lead | Ask vendors when they will support 2026-07-28. Check that gateways can read the new headers. |
| A company that runs its own MCP server | Plan a migration, especially if your code depends on session IDs, Sampling or Roots. |
| A developer | Read the SDK migration notes. Move to MRTR, the Tasks extension and subscriptions/listen. |
The MCP blog says the Tier 1 SDKs for TypeScript, Python, Go and C# supported 2026-07-28 at release. It says the Rust SDK supported it in beta. The blog also warns of "some migration cost, especially for developers that did depend on session identifiers."
If you are scoping that work, our guide to build vs buy for MCP servers can help you decide who should do it. You can also talk to our MCP development team about the work.
Process changes behind the release
Two process updates also shipped. Spec proposals, called SEPs, now follow a formal pull-request workflow with markdown files in a seps/ folder. And the deprecation policy above now governs how features are retired.
These updates come from the same maintainer-led governance described in who owns MCP.
Next step
A stateless protocol is easier to monitor and control, but only if your team sets the rules. Read our guide to MCP governance, logging and access control for IT leaders.
Frequently asked questions
What is the latest MCP specification version?
As of October 2026, the latest version is 2026-07-28, released on 28 July 2026. The previous version was 2025-11-25. MCP versions are named by date rather than by number.
Is the 2026-07-28 spec backward compatible?
Not fully. The release includes breaking changes, such as removing sessions and the initialize handshake. The changelog says clients must treat results from older servers without a resultType field as complete, and SDKs provide migration notes.
Do I need to update my MCP servers right away?
Under the new policy, deprecated features stay in the spec for at least twelve months. The policy allows a shorter window, of no less than ninety days, only for an active security risk. Still, plan the work now if your server uses sessions, Sampling, Roots, Logging or the old HTTP+SSE transport.
What does "stateless" mean for MCP?
Each request carries everything the server needs, including protocol version and client capabilities. The server does not need to remember a session between requests. That makes servers easier to scale and to place behind standard load balancers.
What happened to Tasks in MCP?
Tasks moved from the core protocol into an official extension named io.modelcontextprotocol/tasks. Both client and server must opt in. The redesigned version uses polling and lets the client send input while the task runs.
Where can I read the full list of changes?
The official changelog is at modelcontextprotocol.io under the 2026-07-28 specification. It links to a full comparison on GitHub of every change since 2025-11-25.
