{"slug": "beta-sdks-for-the-2026-07-28-mcp-spec-release-candidate-are-here", "title": "Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here", "summary": "The MCP protocol is releasing its biggest revision since launch, moving to a stateless design that removes the initialize handshake and protocol-level session. Beta SDKs for Python, TypeScript, Go, and C# are available now for testing, with the final specification set for July 28, 2026. Existing servers and clients remain unaffected, and the beta SDKs are opt-in to ensure safe testing.", "body_md": "The MCP protocol is about to undergo its biggest revision since launch. As you might’ve seen\nfrom [our recent release candidate announcement](/posts/2026-07-28-release-candidate/), the new\nprotocol revision goes stateless, removing the `initialize`\n\nhandshake and the protocol-level\nsession, and completing the plan we laid out in\n[The Future of MCP Transports](/posts/2025-12-19-mcp-transport-future/). If you’re building MCP\nservers, you can now scale them using a simple round-robin load balancer, removing the need to\nmanage sticky sessions and to store shared sessions. For client developers, new patterns, like\n[Multi Round-Trip Requests (MRTR)](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr)\nenable a whole new range of possibilities for server-to-client interactions. You can check out\nthe [full changelog](https://modelcontextprotocol.io/specification/draft/changelog) to see\nwhat’s coming.\n\nStarting today you can test all the forthcoming updates to the protocol with all four\n[Tier 1](https://modelcontextprotocol.io/community/sdk-tiers) SDKs, led by\n[Python](https://github.com/modelcontextprotocol/python-sdk) v2 and\n[TypeScript](https://github.com/modelcontextprotocol/typescript-sdk) v2, with\n[Go](https://github.com/modelcontextprotocol/go-sdk) and\n[C#](https://github.com/modelcontextprotocol/csharp-sdk) betas also available. We encourage you\nto run the beta SDKs against your real workloads and tell us what breaks as we inch closer to\nthe actual spec revision. The new protocol specification will be launched on July 28, 2026.\n\n## Your existing server keeps working[#](#your-existing-server-keeps-working)\n\nFirst, we want to reassure you that for existing clients and servers nothing breaks today, and nothing breaks on July 28 either. This is merely the date when the normative specification text is published and is not a switch-off for any implementers relying on the current protocol version.\n\nThe SDK beta releases exist so you can test the protocol changes and give us feedback before the new specification is locked. For any critical workloads, the stable SDK releases remain the recommended versions.\n\nYou might’ve seen that some of the SDKs, like Python and TypeScript, have also switched to v2. Those are new major versions, so moving your own code onto them is a breaking change, and one you can take on your own schedule; it is separate from anything that happens on July 28. Once v2 ships, the TypeScript SDK will continue shipping v1.x bug fixes and security updates for at least six months, and the Python v1.x branch continues to receive critical bug fixes and security patches.\n\nTrying a beta is safe because it is opt-in at every step. Installing the\nPython, Go, or C# SDK without explicitly requesting a pre-release still resolves to\na stable version; the TypeScript v2 packages are new package names with no\nstable release yet, so installing them is itself the opt-in. In the TypeScript and Go\nSDKs, the opt-in extends to the wire: upgrading does not by itself change what your server speaks over\nHTTP. Serving `2026-07-28`\n\nis an explicit choice you make when you wire up\nthe transport. A Python or C# server picks up the new revision on upgrade\ninstead: a Python v2 server answers both protocol revisions from one\nendpoint, and the C# preview’s HTTP transport defaults to the new stateless\nmode. And clients that speak `2026-07-28`\n\nfall back to the\n`initialize`\n\nhandshake when they reach a server on `2025-11-25`\n\nor earlier,\nso old servers and new clients keep interoperating.\n\nIf you want to make sure your own users are not caught out:\n\n- If you publish a library that depends on the Python\n`mcp`\n\npackage, add an upper bound now (for example`mcp>=1.27,<2`\n\n) so the stable v2 release does not surprise your users. - When you test a beta, pin the exact version. Public APIs may still change between the beta and the stable releases.\n\n## What beta SDKs implement[#](#what-beta-sdks-implement)\n\nAll four beta releases implement the core protocol changes from the release candidate,\nwith each release’s notes detailing which changes are covered. The\n[RC announcement](/posts/2026-07-28-release-candidate/) covers the changes\nin depth, but if you’re curious about the short version:\n\n**The stateless core**([SEP-2575](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575),[SEP-2567](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2567)). Every request is self-describing, capabilities come from`server/discover`\n\n, and any server instance can handle any request.**Multi Round-Trip Requests (MRTR)**([SEP-2322](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322)). Tools can return`InputRequiredResult`\n\nto ask the user something mid-call, and the client retries with the answers. No long-lived stream required!**Routable transport headers**([SEP-2243](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2243)).`Mcp-Method`\n\nrides on every request, and`Mcp-Name`\n\non requests that name a tool, resource, or prompt, so gateways and rate limiters can route without parsing bodies.**Authorization hardening**, including`iss`\n\nvalidation per[RFC 9207](https://www.rfc-editor.org/rfc/rfc9207)([SEP-2468](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2468)),`application_type`\n\nin Dynamic Client Registration ([SEP-837](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/837)), scope accumulation on step-up ([SEP-2350](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2350)), and credential binding to the issuing authorization server ([SEP-2352](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2352)). The`application_type`\n\nchange is the one desktop and CLI clients will feel: authorization servers stop defaulting them to`\"web\"`\n\nand rejecting their`localhost`\n\nredirects.**Standard error codes**([SEP-2164](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2164)). A missing resource now returns JSON-RPC`-32602`\n\ninstead of the MCP-custom`-32002`\n\n. If your client matches on the literal value, you should update it.**Deprecation annotations**([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)) on roots, sampling, and logging. This is advisory only, as the deprecated methods, types, and capability flags keep working in this release and in every specification version published within a year of it.\n\nThe full protocol text is in the\n[draft specification](https://modelcontextprotocol.io/specification/draft),\nand the\n[changelog](https://modelcontextprotocol.io/specification/draft/changelog)\nlists every change against `2025-11-25`\n\n.\n\n## Python: `mcp`\n\nv2[#](#python-mcp-v2)\n\nThe v2 line is a rework of the package you already know: `FastMCP`\n\nbecomes\n`MCPServer`\n\n, and the decorator API carries over. A complete server still\nlooks like this:\n\n``` python\nfrom mcp.server import MCPServer\n\nmcp = MCPServer(\"Demo\")\n\n@mcp.tool()\ndef add(a: int, b: int) -> int:\n    \"\"\"Add two numbers.\"\"\"\n    return a + b\n\n@mcp.resource(\"greeting://{name}\")\ndef greeting(name: str) -> str:\n    \"\"\"Greet someone by name.\"\"\"\n    return f\"Hello, {name}!\"\n```\n\nAs in v1, there is no JSON Schema to write, as idiomatic Python constructs take over. Install the beta with an exact pin, since unpinned installs stay on v1.x:\n\n```\nuv add \"mcp[cli]==2.0.0b1\"\n# or\npip install \"mcp[cli]==2.0.0b1\"\n```\n\nIf you have a v1 server today, the\n[migration guide](https://py.sdk.modelcontextprotocol.io/v2/migration/)\nwalks through every breaking change.\n\nOn the protocol side, the beta speaks `2026-07-28`\n\nend to end: servers\nanswer the new `server/discover`\n\nmethod, and the client’s default mode\nprobes it and falls back to `initialize`\n\non older servers. Upgrading your\nserver does not strand existing clients: a v2 server answers the legacy\n`initialize`\n\nhandshake alongside `server/discover`\n\n, so clients on\n`2025-11-25`\n\nkeep connecting. You can test all\nof it in-process: pass your `MCPServer`\n\ninstance directly to `Client`\n\n(`async with Client(mcp) as client:`\n\n) and it connects in memory, the same\npattern as FastAPI’s `TestClient`\n\n. No subprocess, no port. The\n[SDK documentation](https://py.sdk.modelcontextprotocol.io/v2/) has the tutorial and the full\nAPI reference.\n\n## TypeScript: split packages[#](#typescript-split-packages)\n\nTypeScript v2 retires the monolithic `@modelcontextprotocol/sdk`\n\npackage in\nfavor of focused ones, like `@modelcontextprotocol/server`\n\nfor servers,\n`@modelcontextprotocol/client`\n\nfor clients, plus thin adapters for Node.js,\nExpress, Hono, and Fastify. It is ESM-only and runs on Node.js 20+, Bun, and\nDeno. Tool schemas now use\n[Standard Schema](https://standardschema.dev/), so you can bring Zod v4,\nValibot, ArkType, or any compatible library.\n\nYou can bootstrap a minimal server like this:\n\n``` js\nimport { McpServer } from \"@modelcontextprotocol/server\";\nimport { StdioServerTransport } from \"@modelcontextprotocol/server/stdio\";\nimport * as z from \"zod/v4\";\n\nconst server = new McpServer({ name: \"greeting-server\", version: \"1.0.0\" });\n\nserver.registerTool(\n  \"greet\",\n  {\n    description: \"Greet someone by name\",\n    inputSchema: z.object({ name: z.string() }),\n  },\n  async ({ name }) => ({\n    content: [{ type: \"text\", text: `Hello, ${name}!` }],\n  }),\n);\n\nasync function main() {\n  const transport = new StdioServerTransport();\n  await server.connect(transport);\n}\n\nmain();\n```\n\nTo install any of the packages, you can use the now-familiar `npm`\n\ncommands:\n\n```\nnpm install @modelcontextprotocol/server@beta\nnpm install @modelcontextprotocol/client@beta\n```\n\nFor HTTP deployments, which is where the stateless protocol pays off, `createMcpHandler`\n\nfrom\n`@modelcontextprotocol/server`\n\nis the entry point. It serves `2026-07-28`\n\nper request and handles `2025-11-25`\n\ntraffic from the same endpoint, with\nthe adapter packages connecting it to Node.js, Express, Hono, and Fastify.\n\nMigrating from v1 is mostly mechanical, and there is a codemod that does the boring parts\nfor you, including the rename from `.tool()`\n\nto\n`registerTool`\n\nand the error-type renames. You can get it with:\n\n```\nnpx @modelcontextprotocol/codemod@beta v1-to-v2 .\n```\n\nThe repository ships two guides that will help you along the way:\n\nWhile it might seem confusing, these two are standalone steps - you can move to v2\nnow and turn on the new protocol revision when you are ready. The\n[v2 API documentation](https://ts.sdk.modelcontextprotocol.io/v2/) covers\nthe rest.\n\n## Go and C#[#](#go-and-c)\n\nThe Go and C# betas take a slightly gentler path - there is no package split and no rework of the API you use day to day.\n\nThe Go SDK ships `2026-07-28`\n\nsupport in `v1.7.0-pre.1`\n\n, on the same\nmodule path as the version you are already using:\n\n```\ngo get github.com/modelcontextprotocol/go-sdk@v1.7.0-pre.1\n```\n\nServing the new revision over HTTP is the same explicit choice as in\nTypeScript: the streamable HTTP transport accepts `2026-07-28`\n\nonly when\nyou set `StreamableHTTPOptions.Stateless = true`\n\n. Leave it unset and\nclients negotiate down to `2025-11-25`\n\n. The\n[release notes](https://github.com/modelcontextprotocol/go-sdk/releases/tag/v1.7.0-pre.1)\nwalk through every protocol change and the\n[SDK documentation](https://go.sdk.modelcontextprotocol.io) will cover the updated\nAPI.\n\nThe C# beta, in turn, is released as the `2.0.0-preview.1`\n\nversion of the\n`ModelContextProtocol`\n\npackages:\n\n```\ndotnet add package ModelContextProtocol --prerelease\n```\n\nStable v1.x APIs keep working in v2. The breaking changes are confined to\nthe capabilities the specification deprecates (roots, sampling, and\nlogging), which are marked `[Obsolete]`\n\nwith pointers to their\nreplacements, and to experimental APIs whose contracts changed as the\nspecification settled. The\n[preview release notes](https://github.com/modelcontextprotocol/csharp-sdk/releases/tag/v2.0.0-preview.1)\ninclude a per-SEP implementation table, and the\n[SDK documentation](https://csharp.sdk.modelcontextprotocol.io) will have the updated\nAPI reference once the package is stable.\n\n## Give us your feedback[#](#give-us-your-feedback)\n\nWe’re a mere four weeks away until the specification is final. We need your help to make the release smoother!\n\nInstall a beta in a branch of your server and run your real traffic against it, not just the happy path.\n\nIf you operate behind a gateway or load balancer, serve the stateless path and see whether your routing still needs anything the protocol no longer provides. In TypeScript that path is\n\n`createMcpHandler`\n\n; in Go, set`StreamableHTTPOptions.Stateless = true`\n\n; in Python, the v2 HTTP app answers both protocol revisions from one endpoint.File what you find. SDK problems go to the issue tracker for the SDK you are using:\n\nAnd if you spot issues with the protocol itself, go to the\n\n[specification repository](https://github.com/modelcontextprotocol/modelcontextprotocol/issues).\n\nIt’s worth noting that public APIs may still change between the betas and the stable releases, so\npin exact versions. Your feedback in the next four weeks is what they will be\nbuilt from. And if you have other feedback or want to engage with SDK maintainers, join our\n[contributor Discord](https://modelcontextprotocol.io/community/communication#discord).\n\nWe’re excited to see what you build!", "url": "https://wpnews.pro/news/beta-sdks-for-the-2026-07-28-mcp-spec-release-candidate-are-here", "canonical_source": "https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/", "published_at": "2026-06-29 09:00:00+00:00", "updated_at": "2026-07-07 19:34:34.468158+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure", "ai-agents"], "entities": ["MCP", "Python", "TypeScript", "Go", "C#"], "alternates": {"html": "https://wpnews.pro/news/beta-sdks-for-the-2026-07-28-mcp-spec-release-candidate-are-here", "markdown": "https://wpnews.pro/news/beta-sdks-for-the-2026-07-28-mcp-spec-release-candidate-are-here.md", "text": "https://wpnews.pro/news/beta-sdks-for-the-2026-07-28-mcp-spec-release-candidate-are-here.txt", "jsonld": "https://wpnews.pro/news/beta-sdks-for-the-2026-07-28-mcp-spec-release-candidate-are-here.jsonld"}}