TL;DR: MCP’s July 28, 2026 spec revision deletes the initialize handshake and session IDs, turning the protocol into plain stateless request/response. Nothing you run today stops working — adoption is opt-in and new clients fall back to the old handshake. The people with homework are custom MCP server authors, not IDE users.

	Cursor	Cline	Claude Code
Client support for 2026-07-28	Not announced as of Jul 29	Not in v4.0.12 release notes (Jul 28)	Anthropic says rollout “soon” across Claude products
Your local stdio servers	Keep working unchanged	Keep working unchanged	Keep working unchanged
Remote HTTP servers you use	Old handshake still accepted	Old handshake still accepted	First in line for new-spec servers + MCP Tunnels
Action needed today	None	None	None, unless you maintain a server

Honest take: If you only use MCP servers inside an AI coding tool, close this tab — you are fine. If you wrote one that stores anything between calls, start the migration this week, because the SDKs, GitHub, and Cloudflare have already moved and stateful servers are about to be the legacy path.

What actually shipped on July 28

The Model Context Protocol published its fifth spec revision, 2026-07-28, as final on July 28, 2026 — the release candidate had been frozen since May 21, giving SDK maintainers a ten-week validation window. It is the largest change to the protocol since launch, and the headline is architectural: MCP is no longer a stateful, bidirectional session protocol. It is now a stateless request/response protocol, the same shape as every HTTP API you already run.

Under the old 2025-11-25 revision, a client opened with an initialize request, the server answered with a session, and every later request had to carry the same Mcp-Session-Id header back to the same server instance. That was tolerable for one process talking to a local server over stdio. It was miserable for anyone deploying a remote MCP server behind a load balancer: sticky routing, shared session stores, gateways doing deep packet inspection just to figure out which method a request was calling.

The new revision deletes all of that:

• The initialize/initialized handshake is gone, along with the Mcp-Session-Id header. Protocol version, client identity, and capabilities now travel in a _meta field on every request, making each call self-describing. Clients that want upfront capability discovery can call an optional server/discover RPC instead.
• Two new HTTP headers, Mcp-Method and Mcp-Name, let gateways and WAFs route and meter requests without parsing JSON bodies.
• Server-initiated requests are replaced by Multi Round-Trip Requests (MRTR). Instead of holding a Server-Sent Events stream open to ask the user something mid-call, a server now returns resultType: "input_required" with its questions and an opaque requestState; the client re-issues the original call with inputResponses attached.
• List responses are cacheable. tools/list, prompts/list, and resources/list responses now carry ttlMs and cacheScope parameters modeled on HTTP Cache-Control, so clients stop re-fetching tool catalogs on every session.
• Authorization got stricter: RFC 9207 iss validation on authorization responses, a shift from Dynamic Client Registration toward Client ID Metadata Documents, and client credentials keyed to the issuing authorization server.
• Tasks and MCP Apps graduated into a formal extensions framework with reverse-DNS identifiers — Tasks now lives at io.modelcontextprotocol/tasks with poll-based tasks/get and tasks/update.
• Roots, Sampling, and Logging are deprecated, as is the legacy HTTP+SSE transport, each with at least a 12-month removal window. One error-code cleanup lands too: the nonstandard -32002 becomes JSON-RPC’s standard -32602.

Does anything break today? No — here’s the exact compatibility story

This is the part every panicky social media thread gets wrong. The spec release notes say “this release contains breaking changes,” and that’s true for servers that opt in to the new revision. But the maintainers were explicit that nothing already running breaks on July 28, because adoption is opt-in on both sides:

• New clients talking to old servers: a client that speaks 2026-07-28 automatically falls back to the initialize handshake when it reaches a 2025-11-25 server.
• New servers talking to old clients: v2 servers continue to accept legacy handshake requests, so clients can upgrade on their own schedule.
• Serving the new revision is an explicit choice in the SDKs — in the Go SDK, for example, it’s StreamableHTTPOptions.Stateless = true on the HTTP transport.

Your mcp.json full of stdio servers is doubly insulated. Stdio transport is a local pipe between your editor and a child process — there is no load balancer, no session routing problem, and no HTTP header to change. The stateless redesign solves a remote deployment problem that local stdio servers never had.

Cursor: no client update yet, and it doesn’t matter this week

As of July 29, we found no Cursor changelog entry or documentation note announcing client-side support for 2026-07-28 — searches and third-party coverage of the spec release turn up GitHub, Cloudflare, and Anthropic, not Cursor. So Cursor’s MCP client is still speaking 2025-11-25.

Practical consequence for Cursor users: none, today. Every stdio server in your ~/.cursor/mcp.json works exactly as it did on July 27. Remote servers you’ve connected keep accepting the old handshake because the SDKs’ v2 servers are backward compatible. The thing to watch is the first wave of new-spec-only remote servers — a server author who ships stateless-only with no legacy handshake path would be unreachable from Cursor until Cursor ships a client update. Nothing forces authors to do that (the SDKs handle both), but it’s the one realistic gap. If a remote MCP server suddenly stops connecting in Cursor over the next few months, check whether its maintainer went stateless-only before you start debugging your own config — that’s a different failure from the connection-refused class of local Ollama errors we covered earlier this month.

Cline: deepest MCP integration, quietest response so far

Cline has the most MCP surface area of any coding tool — a server marketplace, local server hosting inside the VS Code extension host, the works. That made it the tool we checked most carefully. The verdict from its GitHub releases page: Cline shipped v4.0.12 on July 28 — the same day the spec landed — plus CLI v3.0.47 and Desktop v0.0.7 on July 28–29, and none of the release notes mention the stateless spec. The only MCP item in that window is a marketplace UI cleanup (consistent server cards, single uninstall action).

That silence is fine for the same reason Cursor’s is. The MCP servers Cline runs for you locally are stdio child processes; session state between your extension host and a child process on the same machine was never the problem the spec is solving. Cline’s remote-server connections ride the same backward-compatibility guarantees as everyone else’s. Where Cline users will eventually feel this spec is the good half: ttlMs-based caching of tools/list means a client update can stop re-fetching tool catalogs from your 15 installed marketplace servers on every task, and MRTR gives interactive servers a cleaner way to ask you questions mid-tool-call than the SSE juggling they do now. Watch the Cline releases page for the compatibility release; if you’re choosing servers to install meanwhile, our best MCP servers for AI coding list still applies unchanged.

Claude Code: first mover on the client side

No surprise — MCP is Anthropic’s protocol, and Anthropic published a companion post the day the spec shipped saying support is rolling out across Claude products “soon.” Two concrete items in that announcement matter for Claude Code users specifically:

1. MCP Tunnels — a way to expose internal tools to Claude without inbound firewall rules, public endpoints, or IP allowlisting on the origin. The stateless core is what makes this shape of product viable: if any request can land anywhere, a tunnel doesn’t need to pin sessions.
2. Enterprise-Managed Authorization — Claude Code is listed among the clients supporting the hardened OAuth 2.0/OIDC alignment, which is the piece that lets an MCP server sit behind Entra or Okta without the workarounds enterprises have been duct-taping together.

Claude Code already behaves statelessly from the user’s perspective — each tool call is independent — so expect the client update to be invisible when it lands. If you’ve built out a serious MCP setup there, our Claude Code power user guide covers the config side.

If you maintain a custom MCP server, this is your migration checklist

Here is where real work exists. We hit the canonical failure mode ourselves with a scratch-built browser-automation server: it stored the Playwright browser instance in a session variable keyed by Mcp-Session-Id. Run one instance locally, everything works. Deploy two instances behind round-robin under the new spec and every second click call lands on an instance that has never heard of your browser. The spec’s own migration guidance is the fix: mint an explicit handle. Our server now returns a browser_id from launch_browser, the model passes it back as an ordinary argument on later calls, and instances look the handle up in shared storage — exactly the basket_id pattern the maintainers recommend, and exactly what HTTP APIs have always done.

The concrete steps:

1. Audit for session state. Grep your server for anything written in one handler and read in another — session dicts, instance maps, “current file” pointers. Each one either becomes an explicit handle the client passes back, or moves to external storage.

2. Upgrade to a v2 SDK. The beta SDKs shipped June 29; all four Tier 1 SDKs (TypeScript, Python, Go, C#) now support the final spec, with Rust in beta:

# Python
uv add "mcp[cli]==2.0.0b1"

# Go
go get github.com/modelcontextprotocol/go-sdk@v1.7.0-pre.1

# C#
dotnet add package ModelContextProtocol --prerelease

3. TypeScript authors get a codemod that does the mechanical parts, including the .tool() → registerTool rename:

$ npx @modelcontextprotocol/codemod@beta v1-to-v2 .
# rewrites imports, renames .tool() registrations to registerTool,
# then prints the remaining manual TODOs it could not transform

4. Test against a stateless client. MCP Inspector or Claude Code both work. A quick smoke test that your HTTP server answers self-describing requests without a prior handshake:

curl -s https://your-server.example/mcp \
  -H "Mcp-Method: tools/list" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{"_meta":{"protocolVersion":"2026-07-28"}}}'

A correct v2 server returns your tool catalog with ttlMs in the result — no 400 complaining about a missing session.

5. Check your deprecation exposure. If your server relies on Sampling (asking the client’s model to generate text) or Roots, you have a 12-month window to redesign — Sampling’s replacement path runs through the extensions framework. If you’re still on the old HTTP+SSE transport, move to Streamable HTTP now rather than later.

The ecosystem is moving fast enough that stateless-first is already table stakes for infrastructure: GitHub’s MCP server announced support for the new revision on July 23, five days before the spec went final, and Cloudflare shipped it in Agents SDK v0.20.0 on July 27. For fully open-source migration walkthroughs, aifoss.dev is tracking the self-hosted server side. And if the reason you run MCP servers locally is a local-LLM coding stack, the hardware math for hosting all of it on one box is over at runaihome.com’s VRAM guide.

One security note worth carrying forward

Stateless does not mean safer by default. Every request now carries its own identity in _meta, and the auth hardening (issuer validation, credentials bound to the issuing authorization server) exists precisely because remote MCP servers are becoming ordinary internet infrastructure — with ordinary internet threat models. The Amazon Q credential-theft CVE from earlier this year showed what sloppy MCP trust boundaries cost. Treat the new spec’s auth requirements as a floor, not a ceiling, when you expose a server beyond localhost.

FAQ

Do I need to update my mcp.json or reinstall my MCP servers? No. Local stdio servers are unaffected, and remote v2 servers keep accepting the old handshake. There is no user-facing config change in any coding tool as of July 29.

Will old MCP servers stop working in Cursor, Cline, or Claude Code? Not on any announced timeline. New-spec clients fall back to the initialize handshake when they reach a 2025-11-25 server. The deprecated pieces (Roots, Sampling, Logging, HTTP+SSE transport) carry at least 12-month removal windows.

I built an MCP server with FastMCP in Python — am I affected? If it runs over stdio and keeps no state between calls, a v2 SDK upgrade is close to a no-op — the Python beta (mcp==2.0.0b1) serves both protocol revisions from a single endpoint. If it stores per-session state, refactor to explicit handles before deploying it anywhere horizontal.

What happens to servers that need multi-step user interaction? They move from server-initiated requests over SSE to Multi Round-Trip Requests: return resultType: "input_required" with the questions and a requestState blob, and the client re-calls with inputResponses. It’s poll-shaped instead of push-shaped, and it survives load balancers.

Is this why my remote MCP server got cheaper to host? It will be. Stateless request/response means serverless and edge deployment work without sticky sessions or a shared session store, and ttlMs caching cuts repeated tools/list traffic. Round-robin behind a dumb load balancer is now a supported topology.

Sources

• The 2026-07-28 Specification — Model Context Protocol Blog
• The 2026-07-28 MCP Specification Release Candidate — Model Context Protocol Blog
• Beta SDKs for the 2026-07-28 MCP Spec Release Candidate — Model Context Protocol Blog
• MCP 2026-07-28 spec: stateless core, coming to Claude — Anthropic
• GitHub MCP Server supports the next MCP specification — GitHub Changelog
• Agents SDK adds MCP Specification 2026-07-28 support — Cloudflare Changelog
• Cline releases (v4.0.12, Jul 28 2026) — GitHub

Last verified July 29, 2026. Client support status for Cursor, Cline, and Claude Code reflects public changelogs and release notes on that date; protocol details verified against the official Model Context Protocol blog.