Do I need to reconnect or re-authorize my MCP servers?

Nothing in the spec asks users to reconnect or re-authorize. What you see depends on when your app and each server adopt the new version. If a server you use changes its setup, its own docs are where that shows up. The spec sets a minimum twelve-month deprecation window before a deprecated feature is removed.

Will my older MCP servers stop working?

Not on the spec's release date. The MCP release announcement says Roots, Sampling and Logging "still work, and they'll keep working for at least twelve months." For version differences, the spec adds a server/discover call clients can use as a backward-compatibility probe, and an explicit UnsupportedProtocolVersionError for real mismatches instead of a silent failure.

What does 'stateless' actually mean here?

Older MCP versions opened a persistent, stateful connection between your client and a server, tracked with a session ID. The new spec removes that session concept: each request now carries its own protocol version and capability information, so it can be handled independently — including by a different server instance than the one that handled your last request. That's an infrastructure change for whoever runs the server, not something you configure.

Does this change my OAuth sign-in flow?

The spec adds some OAuth-related requirements aimed at how servers and authorization providers implement things (validating an issuer parameter, a preferred alternative to one client-registration method), but nothing in the sourced material describes a new sign-in step you'd see as a user. If a server you use changes its sign-in screen, that's a change made by that server's operator, not a universal effect of this spec version.

Which AI apps actually run this spec version?

Confirmed only for what each vendor has stated. Anthropic's announcement says support "is rolling out across Claude products soon" — check your Claude app's release notes for where it has landed. This guide does not claim ChatGPT, specific IDEs, or any other client has adopted 2026-07-28 unless that client's own documentation says so — check the specific tool you use for its own compatibility statement.

The 2026-07-28 MCP Spec: What Changes For You

What is this update, in one sentence?

On 2026-07-28, the Model Context Protocol project published a new version of its spec — the rulebook that every MCP client (Claude, an IDE's AI agent, etc.) and every MCP server follow so they can talk to each other. The headline change: MCP moved from tracking an open, stateful connection per session to treating each request as complete and independent on its own. The official changelog frames it this way: MCP removes "protocol-level sessions and the Mcp-Session-Id header," and makes the protocol stateless by removing "the initialize/notifications/initialized handshake" — each request instead carries its own protocol version and client capabilities.

This is a plumbing change. It's aimed at the people who build and operate MCP servers, not at what you click or type as a user of one.

What actually changed? (before vs. after)

Area	Before (2025-11-25 and earlier)	After (2026-07-28)
Connections	Stateful: client and server agree on a session via an `initialize` handshake, tracked with an `Mcp-Session-Id` header	Stateless: every request is self-contained, carrying its own protocol version and capabilities in `_meta`
Cross-call state (e.g. a server that needs to remember something between your requests)	Handled by the session itself	Server mints an explicit handle and passes it back as an ordinary tool argument
Server-to-client notifications (e.g. "your tool list changed")	HTTP GET stream, plus `resources/subscribe`/`resources/unsubscribe`	A single opt-in `subscriptions/listen` stream you (the client) explicitly subscribe to
A dropped connection mid-request	Could sometimes resume via `Last-Event-ID` / SSE event IDs	Resumability is removed — the client re-issues the request fresh with a new request ID
Roots, Sampling, Logging features	Active	Deprecated (still functional, minimum 12-month window)
HTTP+SSE transport	Deprecated since 2025-03-26	Formally reclassified as Deprecated
OAuth client registration	Dynamic Client Registration (DCR) was the norm	Client ID Metadata Documents (CIMD) is the new preferred path; DCR still works for backward compatibility
Long-running / async tool calls	Experimental "tasks" in the core protocol	Moved into an official, versioned extension with polling (`tasks/get`) instead of a blocking wait

Source for the left/right technical details: the official changelog's "Major changes" and "Deprecated" sections at modelcontextprotocol.io/specification/2026-07-28/changelog.

Will I notice anything when I use MCP servers in Claude, ChatGPT, or an IDE?

Mostly, no. The stateless redesign is meant to be invisible from where you sit — it changes what happens between the client app and the server behind the scenes, not the buttons or prompts you see. A few things that could theoretically surface:

Fewer stuck/broken-connection states in theory. Because requests are self-contained and can land on any server instance, a server operator can now run their MCP endpoint behind a normal load balancer instead of pinning your session to one machine. If that reduces flaky reconnects for a given server, that's a benefit of how that operator deploys it — not something the spec forces to happen everywhere at once.
A server you use might change its own sign-in or setup flow as its maintainers adopt the new spec (for example, moving off Dynamic Client Registration to Client ID Metadata Documents). The changelog is explicit that DCR "remains available for backwards compatibility," so this is not something every server is required to change on this date.
New capabilities may show up in specific clients. Anthropic's post about this spec version describes Claude features built on MCP, such as MCP Apps (interactive UI inside a conversation) and enterprise-managed auth (admins provisioning connectors org-wide), and says support for the new spec "is rolling out across Claude products soon." Those are product features of one client, not something every client gets automatically.

Do I need to do anything?

If you use MCP servers rather than build them, the spec itself asks nothing of you. Specifically:

You don't need to reinstall, reconnect, or re-authorize anything because of this spec update by itself.
Your existing MCP servers should keep working. The spec's feature-lifecycle policy guarantees "a minimum twelve-month deprecation window" before a deprecated feature is actually removed, and the MCP release announcement says Roots, Sampling and Logging "still work, and they'll keep working for at least twelve months."
If you build or run an MCP server yourself, that's where the real work is — the MCP release announcement notes there will be "some migration cost, especially for developers that did depend on session identifiers," and points to migration notes shipped with the official SDKs (TypeScript, Python, Go, C#).
Watch for individual server announcements, not the spec date. If a specific MCP server you rely on tells you it's dropping support for an older client or changing how you sign in, that's a decision made by that server's maintainer, within the spec's compatibility window — not something this spec version mandates on its own.

Is this compatible with older servers and clients?

Yes, by design, for the deprecation window. The spec adds a server/discover call so a client can ask a server up front which protocol versions and capabilities it supports, and defines an explicit UnsupportedProtocolVersionError for genuine mismatches — rather than a silent failure. Deprecated features (Roots, Sampling, Logging, the older HTTP+SSE transport, Dynamic Client Registration) continue to function during the window; they're marked for eventual removal, not switched off on 2026-07-28.