Skip to content
News Product launch

MCP 2026-07-28 spec release candidate ships beta SDKs, drops the initialize handshake, and goes fully stateless

· by Pondero Newsdesk

The short version

The Model Context Protocol published beta SDKs for Python, TypeScript, Go, and C# on June 29, 2026, covering the largest protocol revision since the November 2024 launch. The new spec removes the session handshake so any MCP server can run behind a plain round-robin load balancer.

MCP 2026-07-28 spec release candidate ships beta SDKs, drops the initialize handshake, and goes fully stateless

On June 29, 2026, the Model Context Protocol project released beta SDKs for all four Tier-1 languages, Python, TypeScript, Go, and C#, implementing the largest revision to the protocol since its November 2024 launch. The final spec publishes on July 28. Server builders and client implementers now have a 10-week window to validate against real workloads before the specification locks.

What changed in the protocol

The headline change is the elimination of the initialize handshake and the protocol-level session ID. Under the outgoing 2025-11-25 revision, every client opens a session before calling any tool. The server returns an Mcp-Session-Id header, and every subsequent request must carry it, which pins traffic to the instance that issued the session. That pin is why production deployments needed sticky sessions and shared session stores at the load balancer, per the MCP RC announcement.

Under 2026-07-28, each request is self-describing. Capabilities are served from a new server/discover endpoint rather than negotiated at session open. A new Mcp-Method header lets any gateway route requests without parsing the JSON body, and an Mcp-Name header identifies the specific tool, resource, or prompt being called. The upshot: a remote MCP server can sit behind a plain round-robin load balancer with no sticky-session config and no shared state store.

Six Specification Enhancement Proposals (SEPs) deliver the stateless core. Alongside them, the RC ships the Multi Round-Trip Requests (MRTR) extension, which lets a tool return an InputRequiredResult mid-call to request additional input from the user, avoiding the need for a long-lived stream to handle back-and-forth. A Tasks extension covers long-running work. MCP Apps adds server-rendered UI surfaces. Authorization tightens around OAuth and OpenID Connect, adding iss validation per RFC 9207, application_type in Dynamic Client Registration, and scope accumulation on step-up auth, all per the RC specification page.

Three features from the current spec are deprecated but not removed: roots, sampling, and logging. The deprecation is advisory. The deprecated methods and capability flags continue to work in 2026-07-28 and in every spec version published within a year of it.

What the SDK betas deliver today

All four Tier-1 SDK betas implement the core protocol changes, with each release's notes detailing exact coverage.

Python gets a new major version, mcp v2. The FastMCP class is renamed MCPServer; the decorator API otherwise carries over. A beta install requires an explicit version pin, per the official SDK beta post: pip install "mcp[cli]==2.0.0b1". Unpinned installs stay on the v1.x stable line.

TypeScript takes a different approach: the v2 SDK splits into new package names rather than a version bump on the existing package, making the opt-in explicit. The v1.x branch will continue receiving bug fixes and security patches for at least six months after v2 stable ships.

Go and C# betas are also available. The C# preview's HTTP transport defaults to the new stateless mode, while Go requires an explicit choice to serve the 2026-07-28 wire format.

A critical compatibility note from the MCP maintainers: clients that speak 2026-07-28 fall back to the initialize handshake when they reach a server on 2025-11-25 or earlier, so old servers and new clients stay interoperable during the transition window.

One tooling note for Python library authors: if a library depends on the mcp package, the maintainers recommend adding an upper bound now, for example mcp>=1.27,<2, to avoid v2 landing unexpectedly on users when the stable release ships.

Why it matters for operators

The stateless change is the one with the sharpest near-term consequence for anyone running MCP servers at scale. Session stickiness is an operational burden: it constrains horizontal scaling, complicates failover, and requires session-aware load balancer config or a distributed session store. Removing it at the protocol layer means a Python v2 server can sit behind a standard HTTP gateway with no MCP-specific plumbing.

For client-side tool builders, the MRTR extension opens up interaction patterns that were impractical before. A tool that needs to confirm a destructive action, request a file path, or ask a clarifying question no longer requires a streaming connection or a bespoke callback mechanism. The server pauses, returns InputRequiredResult, and the client resumes with the answer.

The authorization tightening closes a gap that blocked production deployments in enterprise settings. The application_type change in Dynamic Client Registration specifically addresses desktop and CLI clients, which authorization servers previously defaulted to the web type and then rejected because their redirect URIs pointed to localhost. That mismatch was a known friction point for Cursor and Claude Code users configuring OAuth-protected MCP servers. Cursor users in particular will want to watch for client-side updates that adopt the new 2026-07-28 authorization spec once the SDK betas stabilize. If your team uses Cursor and builds or operates MCP servers, testing your OAuth flows against the beta SDKs before July 28 is practical preparation.

The formal deprecation policy itself is notable. The 2025-11-25 spec removed the original SSE transport without a grace period, which broke existing integrations. The new policy commits to keeping deprecated features functional for at least one year of spec versions, giving implementers a predictable migration runway.

Context

The stateless architecture was telegraphed in December 2024, when the MCP team published "The Future of MCP Transports," outlining the plan to decouple the protocol from connection state. The RC arriving in May 2026, with SDK betas in late June, puts the spec on schedule with the roadmap the team published earlier this year.

Standard error codes, another RC change, align MCP's JSON-RPC error numbers with the wider ecosystem. A missing resource now returns -32602 instead of the MCP-custom -32002. Clients that match on the literal value need updating before July 28.

The mcp.directory secondary source, which covered the RC announcement in depth, identifies the client-side tools/list caching as a meaningful throughput improvement for chatty integrations. Because tools/list responses now carry a server-specified ttlMs, clients can avoid re-fetching the tool manifest on every session open. That was a measurable round-trip cost in the previous architecture.

What to watch next

Stable SDK releases, particularly Python mcp v2 stable and the new TypeScript v2 packages, need to land before the July 28 spec date for the migration window to be useful. Watch the python-sdk and typescript-sdk GitHub repositories for stable tags.

Client-side adoption is the second variable. Cursor and Claude Code are the two highest-volume clients in the MCP ecosystem. Both will need to ship 2026-07-28 transport support before the new authorization changes and MRTR capabilities are usable end-to-end. Neither team has published a timeline for 2026-07-28 client support as of this writing.

Sources