MCP SDK Migration: The 2026-07-28 Spec's Hidden Costs

The MCP ecosystem has grown to nearly 9,650 servers in the official registry as of August 2026 the MCP ecosystem reaching 9,650 servers, but the protocol’s largest revision since launch is creating a hidden tax that most migration guides skip. The 2026-07-28 Model Context Protocol specification is final and transitions MCP from a stateful bidirectional protocol to a stateless request/response protocol, removing the initialize/initialized handshake and Mcp-Session-Id header the 2026-07-28 MCP specification. Google co-founded the MCP Transports Working Group and led the charge for the stateless 2026-07-28 specification to enable scaling across millions of concurrent queries on Google Cloud the Google Developers Blog. The marketing is straightforward: horizontal scaling via plain load balancers, no sticky sessions, no shared session stores. The reality is that the protocol’s stateless design increases total system state; it merely moves state from visible infrastructure to invisible application requirements. I call this pattern state externalization, and it’s the lens through which every migration cost should be evaluated.

What actually changed in the 2026-07-28 spec?

The headline change is the removal of protocol-level sessions. The initialize/initialized handshake is gone, and with it the Mcp-Session-Id header that pinned clients to specific server instances the 2026-07-28 MCP specification. In their place, every request carries its own protocol version and client capabilities in the params._meta field, so any worker behind a load balancer can answer any request the MCP Gateway documentation. That shift eliminates the need for sticky routing and shared session stores, which is exactly what teams running MCP in production requested most often. For local stdio servers, the change is invisible. For remote HTTP servers, it’s an infrastructure simplification that removes an entire class of operational complexity.

The revision also introduces Multi Round-Trip Requests (MRTR) to replace server-initiated elicitation, sampling, and roots/list calls WorkOS’s analysis of the stateless spec. Where a server previously opened a persistent stream to ask the client a question, it now returns an interim result with resultType: “input_required” and expects the client to retry with answers attached. That’s not a rename; it’s a different control flow that forces tools to be idempotent whether they were designed that way or not. The elicitation rewrite is an architectural inversion, not a rename, and it carries no deprecation window for the old callback pattern WorkOS’s analysis of the stateless spec.

Three original primitives—Roots, Sampling, and Logging—are deprecated with a twelve-month minimum window, not removed the 2026-07-28 MCP specification. That gives teams breathing room, but it also means the migration timeline is measured in quarters, not days. With nearly 9,650 servers in the registry and growing the MCP ecosystem reaching 9,650 servers, the migration queue is long, and the teams that treat this as a simple dependency upgrade will absorb costs that don’t appear on any infrastructure invoice. The spec also formalizes an extensions framework, with Tasks joining MCP Apps and Enterprise Managed Authorization as first-class extensions the 2026-07-28 MCP specification. That’s useful context, but it’s not what’s breaking your code this quarter.

Which changes will actually break your code?

Most of the revision is find-and-replace work. For typical servers, only two changes are hard-breaking: the missing-resource error code moves from -32002 to the standard JSON-RPC -32602, and tool input/output schemas must be valid JSON Schema 2020-12 the migration checklist from Dreaming Press. Everything else is annotation, deletion, or restructuring. That’s the good news. The bad news is that the two changes that will cost you the most don’t announce themselves as breaking.

Stream resumability via Last-Event-ID is removed, creating a silent reliability regression where dropped streams lose in-flight requests outright WorkOS’s analysis of the stateless spec. Under the old transport, a broken stream could be resumed and undelivered messages redelivered. Now the client has to re-issue the request with a new request ID, and nothing errors when you migrate. Your tests pass. What you get instead is a quiet reliability regression that only shows up under real network conditions, as occasional lost tool calls WorkOS’s analysis of the stateless spec. For an idempotent read that’s harmless. For a tool that charges a card, sends an email, or provisions something, a lost request that the client then retries is a duplicated side effect. The spec does not solve this for you: side-effecting tools need an idempotency key supplied as a parameter, and that is application work nobody will prompt you to do.

The elicitation rewrite compounds the problem. If you built on the 2025-11-25 elicitation design, notifications/elicitation/complete and the elicitationId field were removed outright, not deprecated WorkOS’s analysis of the stateless spec. There is no twelve-month window on these. The replacement, multi round-trip requests, turns a callback into a retry loop, and tools must be idempotent to survive it. If your tool writes to a database or calls a payment API, you need to implement idempotency keys before you cut over, not after you discover the first duplicate charge.

Every Streamable HTTP POST must include MCP-Protocol-Version, Mcp-Method, and Mcp-Name headers, with protocol version and client capabilities supplied in params._meta on every request the MCP Gateway documentation. Miss one header and the request fails at the gateway, not in your application code, which makes debugging a routing problem feel like a schema problem. The mandatory headers are easy to implement but easy to miss in custom transport layers, and they’re not optional for servers that want to speak the new protocol.

What’s the real cost of staying stateful?

The protocol is open and free, but the engineering around it is not. Building a production multi-tenant SaaS MCP server from scratch costs roughly $60,000 to $120,000 before maintenance, with ongoing maintenance of $5,000–$25,000 per month Albato’s build vs buy analysis. Those numbers capture development, hosting, security, and tenant isolation, but they miss the hidden line items that the stateless transition either eliminates or exposes.

The AWS ElastiCache for Valkey session store example costs approximately $2,500 per month, which can be eliminated by migrating to the stateless 2026-07-28 spec eCorpIT’s migration guide. That’s a visible infrastructure cost disappearing. Less visible is the token tax from repeated tool definition transmission. Operating at scale, five common MCP servers can present 55,000 tokens of tool definitions per conversation, which at Opus 5 list prices costs approximately $55,000 per month for a fleet handling one million agent tasks per month research on tool definition token costs. Under the old stateful protocol, those definitions could be cached at the session level. Statelessness means they ride on every call, and the team paying for them usually cannot see it because the cost hides inside a much larger inference bill research on tool definition token costs.

The token tax is not a protocol bug; it’s a protocol feature. List responses carry cache hints and a deterministic order, so clients can cache tool catalogs and keep upstream prompt caches stable across reconnects the 2026-07-28 MCP specification. But if your client doesn’t implement that caching—or if a gateway in the path strips the cache headers—you’re paying for those 55,000 tokens on every single call. The budget owner sees an invoice “by API key or project, not by business unit, cost center, application, or team” research on tool definition token costs, so the team controlling the gateway doesn’t always connect the token spike to the MCP tool surface.

How do the SDKs actually stack up?

The official TypeScript SDK has split into scoped packages (@modelcontextprotocol/core, /server, /client, /express) for v2, while the legacy @modelcontextprotocol/sdk remains on v1.30.0; Python’s mcp package is at 2.0.0+ on PyPI the Context Studios v2 vs v1 comparison. That asymmetry is not a temporary publishing delay. The core TypeScript package that almost every custom client imports is still on v1.30.0, while server packages have moved to v2.0.0 stable the Context Studios v2 vs v1 comparison. If you’re maintaining a custom client in TypeScript, you cannot upgrade to v2 yet. If you’re building servers, you can—and the How to Build an MCP Server in Node.js and How to Build an MCP Server in Python guides cover the current SDK shapes and the import renames that break v1 code.

The MCP C# SDK v2.0 implements the 2026-07-28 spec and is backward compatible, with the HTTP server transport running statelessly by default the .NET Blog announcement. That’s the cleanest migration path of the four Tier 1 SDKs: upgrade, get stateless behavior automatically, and keep your existing v1 code compiling. For TypeScript and Python, the migration is more deliberate. You have to choose which packages to upgrade, and you have to verify that your gateway and adapters support the new mandatory headers before you cut over.

SDK	Pricing	Target Audience	Stateless Default
TypeScript (scoped v2)	Free / Open Source	Node.js/edge serverless	Yes (v2 packages)
Python (mcp 2.0.0+)	Free / Open Source	Data tools, local CLIs	Yes
C# (v2.0)	Free / Open Source	.NET/ASP.NET Core shops	Yes

The table makes the asymmetry clear: all three are free and open source, but their migration readiness differs. The TypeScript split means teams depending on @modelcontextprotocol/sdk itself—client code and anything built on the core SDK—have no v2 to install. Python and C# server authors can move now; TypeScript client authors must wait or pin. The SDKs themselves are not the bottleneck; the ecosystem fragmentation around them is.

What’s the actual MCP SDK migration path?

Here’s the part most coverage gets wrong: nothing switches off on July 28. v2 MCP servers accept the legacy 2025-11-25 initialize handshake alongside the new protocol, so nothing force-breaks on July 28 and migration can be gradual the MCPOrbit migration guide. That’s not panic framing; that’s the SDK maintainers’ stated position. The panic framing creates urgency that, in most cases, wasn’t warranted. The July 2026 Stateless MCP Spec Migration: Remote Server Guide covers the infrastructure changes for teams that need to move faster.

The servers that must act first are remote HTTP servers that depend on sticky sessions or a shared session store the MCPOrbit migration guide. If your server runs over local stdio, or is already stateless behind a plain load balancer, you have more time. Do this now regardless of your transport: install the v2 SDK and run your test suite against it. On October 2, 2026, three security advisories were published for MCP SDKs: GHSA-6prh-2h8m-c8cw (TypeScript redirect bug, fixed in 1.32.0/2.3.0), GHSA-5h93-6whr-6q8j (Python redirect bug, fixed in 1.30.0/2.2.0), and GHSA-22jm-h49p-29qw (TypeScript task store session bug, fixed in 1.32.0) the October 2 security advisories. The fixes are already shipped, but they only apply if you’re on the patched versions. If you’re still on v1.31.0 or v2.1.1, you’re exposed to a redirect bug that carries custom headers and request bodies to arbitrary origins the October 2 security advisories.

The migration requires budgeting for application-level idempotency, explicit access control, and tool catalog optimization before cutover, not after. The teams that treat this as a simple dependency upgrade will absorb a hidden tax of duplicated side effects, token overages, and authorization bugs. The spec makes scaling easier; it makes operations harder. If your server runs over HTTP and depends on sticky sessions, start the migration now. If it runs over stdio, install the v2 SDK and run your test suite, but don’t rewrite working code until you’ve accounted for the hidden tax.