MCP 2026-07-28 Specification Makes the Model Context Protocol Stateless: What Changes

The Model Context Protocol (MCP) is the open standard that lets AI assistants and agents connect to outside tools and data: your CRM, your order database, your document store. On July 28, 2026, the project's lead maintainers published the 2026-07-28 specification, and it is the largest structural change to the protocol since the previous revision, dated 2025-11-25.

If your company has built an MCP server, pays a vendor that offers one, or is planning custom software development that involves AI agents, this release affects how that software is hosted, secured and maintained. The headline is that MCP is now stateless at the protocol level, and several older features have been put on a published removal path.

This article explains what was released, what was deprecated, and what a non-technical decision maker should ask their development team.

What was released on July 28, 2026

According to the announcement on the MCP blog, the 2026-07-28 revision is a stable release, not a draft. The post lists a stateless protocol core, a new pattern called Multi Round-Trip Requests, header-based routing, cacheable list results, stricter authorization rules and a formal extensions framework.

The same post states that all four Tier 1 SDKs (TypeScript, Python, Go and C#) support the new revision as of the release date, and that the Rust SDK supports it in beta. That matters because most teams do not implement the protocol by hand. They upgrade an SDK, and the SDK does the protocol work.

The main change: MCP no longer keeps sessions

In earlier revisions, a client and a server opened a connection with a handshake and then shared a session, identified by a session ID header. Every later request depended on that session. In practice this meant a server had to remember each client, or several server instances had to share session storage.

The official changelog says the new revision removes protocol-level sessions and the session ID header, and removes the opening handshake. Instead, every request carries its own protocol version and client capabilities. The blog post describes the practical result: any request can be handled by any server instance behind an ordinary round-robin load balancer, without shared storage.

The maintainers are clear that an application can still hold state. The changelog says servers that need to remember something across calls should issue their own explicit handle and have it passed back as a normal tool argument. A shopping cart or a multi-step report can still exist. It is simply the application's job to track it, not the protocol's.

Other changes that affect how MCP servers are run

Asking the user for input without holding a connection open

Previously, when a tool needed something from the user in the middle of a call, the server sent its own request back to the client over a connection that had to stay open. The changelog replaces this with Multi Round-Trip Requests: the server returns a result marked as needing input, and the client retries the original request with the answers attached.

Routing and caching

The changelog now requires two standard headers on HTTP requests that name the method and the target being called. The blog post explains the benefit: gateways, rate limiters and web application firewalls can route and meter traffic from the headers without parsing each request body. Results that list tools, prompts and resources must also carry a freshness hint and a cache scope, so clients can cache them and poll less often.

Authorization rules

The changelog tightens the OAuth-based sign-in flow in three ways. Clients must validate the issuer value on an authorization response, when one is present, before redeeming the code. Client credentials are bound to the authorization server that issued them and must not be reused with another. And Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents, although it stays available for backward compatibility.

What has been deprecated, and the twelve-month window

This release also introduces a governance change. The changelog records the adoption of a feature lifecycle and deprecation policy with three states (Active, Deprecated and Removed) and a minimum twelve-month deprecation window.

Under that policy, the changelog lists the following as deprecated. They still work, but new implementations should not adopt them:

• The Roots, Sampling and Logging features.
• The older HTTP+SSE transport, which had already been marked deprecated in an earlier revision and is now formally on the removal path. The replacement is Streamable HTTP.
• Dynamic Client Registration as a way for clients to register with an authorization server.

The blog post says the deprecated features will keep working for at least twelve months. It does not give a calendar date for removal, so treat July 2027 as the earliest point at which removal could happen, not as a confirmed deadline. The policy also notes that features may stay deprecated for much longer than the minimum, and that the window can be shortened only where a feature presents an active security risk.

One item moved rather than being deprecated. Tasks, which let a server run long jobs, were experimental in the core protocol. The changelog moves them into an official extension with a redesigned, polling-based approach. If your team built on the experimental version, that code will need rework.

What this means for your business

The following is our reading of the release, offered as guidance and not as a statement from the MCP project.

For companies hosting their own MCP servers, the stateless design should make hosting simpler. Infrastructure that had to keep a client pinned to one server, or share session data between servers, can in principle be replaced with a standard load-balanced setup or a serverless deployment. Whether that reduces your hosting bill depends on your traffic and your current architecture, so ask for an estimate instead of assuming a saving.

For companies whose MCP server relied on sessions, there is real migration work. The blog post itself acknowledges a migration cost for developers who depended on session identifiers. A server that stored per-user context in the session needs to be redesigned around explicit handles.

For companies that only consume MCP through a product, such as an AI assistant connected to a vendor's MCP server, the work sits mostly with the vendors. The reasonable step is to ask each vendor when they will support the 2026-07-28 revision and whether they still depend on anything on the deprecated list.

Compatibility between old and new versions deserves a specific question to your developers. The changelog says a version mismatch returns a defined error, and that servers must implement a discovery call that advertises which protocol versions they support. It does not promise that every older client will work with every newer server. Test the combinations you actually use.

What to do next

A short review now is cheaper than a rushed migration later. We would suggest the following order:

• Inventory. List every MCP server you run and every third-party MCP server your AI tools connect to, with the SDK and protocol revision each one uses.
• Check for deprecated features. Ask whether any server uses sessions, the HTTP+SSE transport, Roots, Sampling, Logging, experimental Tasks or Dynamic Client Registration.
• Plan the upgrade. Schedule the SDK upgrade and any redesign inside the deprecation window, and retest authorization flows, since those rules changed.
• Review the perimeter. If you run an API gateway or firewall in front of MCP servers, ask whether it can now use the new headers for routing and rate limiting.

If you are still deciding whether your project needs agents at all, our earlier guide to AI agents, chatbots and workflow automation covers that decision.

Conclusion

The 2026-07-28 MCP specification, published on July 28, 2026, removes sessions and the opening handshake, changes how servers ask users for input, adds routing headers and caching hints, tightens authorization, and puts several older features on a minimum twelve-month path to removal. New projects should build against this revision. Existing MCP servers should be checked for session use and deprecated features before the window closes.

Entrant Technologies builds websites, web applications, mobile apps and custom software. If you would like help reviewing an existing MCP integration or planning a new one, you can contact our team to talk it through.