Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here | Model Context Protocol BlogSkip to content<br>Table of ContentsYour existing server keeps working<br>What beta SDKs implement<br>Python: mcp v2<br>TypeScript: split packages<br>Go and C#<br>Give us your feedback

The MCP protocol is about to undergo its biggest revision since launch. As you might&rsquo;ve seen<br>from our recent release candidate announcement, the new<br>protocol revision goes stateless, removing the initialize handshake and the protocol-level<br>session, and completing the plan we laid out in<br>The Future of MCP Transports. If you&rsquo;re building MCP<br>servers, you can now scale them using a simple round-robin load balancer, removing the need to<br>manage sticky sessions and to store shared sessions. For client developers, new patterns, like<br>Multi Round-Trip Requests (MRTR)<br>enable a whole new range of possibilities for server-to-client interactions. You can check out<br>the full changelog to see<br>what&rsquo;s coming.<br>Starting today you can test all the forthcoming updates to the protocol with all four<br>Tier 1 SDKs, led by<br>Python v2 and<br>TypeScript v2, with<br>Go and<br>C# betas also available. We encourage you<br>to run the beta SDKs against your real workloads and tell us what breaks as we inch closer to<br>the actual spec revision. The new protocol specification will be launched on July 28, 2026.

Your existing server keeps working#<br>First, we want to reassure you that for existing clients and servers nothing breaks today,<br>and nothing breaks on July 28 either. This is merely the date when the normative specification<br>text is published and is not a switch-off for any implementers relying on the current protocol<br>version.<br>The SDK beta releases exist so you can test the protocol changes and give us feedback<br>before the new specification is locked. For any critical workloads, the stable SDK releases<br>remain the recommended versions.<br>You might&rsquo;ve seen that some of the SDKs, like Python and TypeScript, have also switched to v2.<br>Those are new major versions, so moving your own code onto them is a breaking change, and one<br>you can take on your own schedule; it is separate from anything that happens on July 28.<br>Once v2 ships, the TypeScript SDK will continue shipping v1.x bug fixes and security updates<br>for at least six months, and the Python v1.x branch continues to receive critical bug fixes and<br>security patches.<br>Trying a beta is safe because it is opt-in at every step. Installing the<br>Python, Go, or C# SDK without explicitly requesting a pre-release still resolves to<br>a stable version; the TypeScript v2 packages are new package names with no<br>stable release yet, so installing them is itself the opt-in. In the TypeScript and Go<br>SDKs, the opt-in extends to the wire: upgrading does not by itself change what your server speaks over<br>HTTP. Serving 2026-07-28 is an explicit choice you make when you wire up<br>the transport. A Python or C# server picks up the new revision on upgrade<br>instead: a Python v2 server answers both protocol revisions from one<br>endpoint, and the C# preview&rsquo;s HTTP transport defaults to the new stateless<br>mode. And clients that speak 2026-07-28 fall back to the<br>initialize handshake when they reach a server on 2025-11-25 or earlier,<br>so old servers and new clients keep interoperating.<br>If you want to make sure your own users are not caught out:<br>If you publish a library that depends on the Python mcp package, add an<br>upper bound now (for example mcp>=1.27,) so the stable v2 release does<br>not surprise your users.<br>When you test a beta, pin the exact version. Public APIs may still change<br>between the beta and the stable releases.<br>What beta SDKs implement#<br>All four beta releases implement the core protocol changes from the release candidate,<br>with each release&rsquo;s notes detailing which changes are covered. The<br>RC announcement covers the changes<br>in depth, but if you&rsquo;re curious about the short version:<br>The stateless core<br>(SEP-2575,<br>SEP-2567).<br>Every request is self-describing, capabilities come from<br>server/discover, and any server instance can handle any request.<br>Multi Round-Trip Requests (MRTR)<br>(SEP-2322).<br>Tools can return InputRequiredResult to ask the user something<br>mid-call, and the client retries with the answers. No long-lived stream<br>required!<br>Routable transport headers<br>(SEP-2243).<br>Mcp-Method rides on every request, and Mcp-Name on requests that name<br>a tool, resource, or prompt, so gateways and rate limiters can route<br>without parsing bodies.<br>Authorization hardening , including iss validation per<br>RFC 9207<br>(SEP-2468),<br>application_type in Dynamic Client Registration<br>(SEP-837),<br>scope accumulation on step-up<br>(SEP-2350),<br>and credential binding to the issuing authorization server<br>(SEP-2352).<br>The application_type change is the one desktop and CLI clients will<br>feel: authorization servers stop defaulting them to "web" and<br>rejecting their localhost redirects.<br>Standard error codes<br>(SEP-2164).<br>A missing resource now returns JSON-RPC -32602 instead of the<br>MCP-custom -32002. If...