MCP Specification Update: What Changed in July 2026

The latest MCP specification update is revision 2026-07-28. Its big change is that MCP is now stateless: the startup handshake and session ID are gone, and each request carries its own version and capabilities. It also adds a required discovery call and deprecates a few features. If you only use MCP servers, most of this happens behind the scenes.

What changed, in one example

Say your AI app talks to a server. Under the older revisions, it first sent an initialize request, waited for the answer, sent a notifications/initialized message, and then carried an Mcp-Session-Id header on every later call.

Under 2026-07-28, none of that exists. The app just sends the request, and puts its protocol version and capabilities in the request's _meta field. Any server instance can answer it, with no memory of an earlier conversation.

That's the core idea. The rest of the update follows from it.

What "current" means here

As of September 2026, the official versioning page marks 2026-07-28 as Current. MCP revisions are named by date, and a new date means a backward-incompatible change. Older revisions marked Final are complete.

Keep four version numbers apart when you debug: the protocol revision, your SDK version, your client app version and your server package version. They answer different questions. Upgrading an SDK doesn't prove your own request handling follows the new rules.

Stateless requests

The changelog removes the initialize handshake and the Mcp-Session-Id header. A server that needs to remember something across calls now uses an explicit handle passed in ordinary tool arguments.

If you build servers, look for code that assumes initialization stored everything, and for routing that sticks a user to one worker. Decide what data must persist and make it part of the tool's design.

Stateless doesn't mean anonymous. Every request still needs proper authorization, and your app can still keep jobs, transactions or other durable data.

Discovery with server/discover

The new server/discover call reports a server's supported versions, capabilities and identity. Servers on the current revision must implement it. Clients may call it first, or send a request directly and handle a version error.

So a log with no discovery call doesn't mean a client is broken. And a good discovery answer doesn't prove a tool works. Treat it as a description of the interface, then test the tools you need. Server identity is self-reported, so it isn't a trust check.

Streamable HTTP keeps its name, changes its behavior

The current transport spec drops the standalone GET stream and session handling. It also drops resumable streams (SSE event IDs and Last-Event-ID). If a response stream breaks, the in-flight request is lost, and retrying it uses a new request ID.

That matters for writes. Say a tool succeeds upstream, but the connection drops before the client hears back. A new request ID doesn't tell you the action didn't happen. Use an idempotency key, your own operation ID or a status check before retrying.

Follow-up input and caching

More input means another round trip

The Multi Round-Trip Requests pattern replaces server-initiated requests. When a server needs more information, it returns an input_required result. The client collects the answer and retries the original call with inputResponses. If the server sent requestState, the client passes it back untouched.

Test this path separately from a normal success. Your UI must not show an "input required" result as the final answer. And servers shouldn't trust requestState just because it came back from the client.

Cache hints

The caching spec adds ttlMs and cacheScope to results from discovery, list calls and resource reads. A private result belongs to one caller's authorization context and can't be shared with another.

To check this, request the same resource with two test identities that have different permissions, and confirm nothing leaks between them. A freshness hint doesn't guarantee the data hasn't changed.

What is deprecated

The changelog deprecates Roots, Sampling, Logging and the older HTTP+SSE transport. Experimental tasks move into an official extension. Deprecated doesn't mean removed. The feature lifecycle policy sets a normal minimum window of twelve months, and an exception for an active security risk can shorten it to ninety days.

Don't rewrite everything. List which deprecated features your code really uses, what replaces each, and which clients need to move. A server that only offers basic read tools has almost nothing to migrate. One that relies on sampling has real work.

What this means for MCPifex users

MCPifex's gateway uses the handshake-based MCP transport. Clients on the current revision interoperate through the spec's backward-compatibility rules. A client that supports both eras can fall back. A client that speaks only the new one can't be assumed to work with a server that speaks only the old one.

The setup steps for MCPifex don't change. The quickstart and authentication docs are still the reference. If a connection breaks after a client upgrade, note the client version, transport and error, and see the troubleshooting page. For which apps connect at all, see which AI clients support MCP.

Before you adopt the new revision

1. Find out which protocol eras your client, gateway and server support.
2. Check discovery and run one small read on your real connection path.
3. Test unsupported-version errors, input_required results and dropped connections.
4. Check caching and write retries with test data and two identities.
5. Keep a rollback config, and decide in advance what triggers it.

Write down what works, what stays on the older protocol and what still needs work. Update that note whenever either end changes.