The MCP 2026-07-28 Rewrite: What Breaks and How to Migrate

Official Sources

The next version of the Model Context Protocol lands on July 28, 2026, and the maintainers are calling it the largest revision since launch. This is not a point release with a few new fields. The 2026-07-28 spec rewrites the core transport model, deprecates three long-standing features, hardens authorization, and promotes two extensions to first-class status.

If you build, host, or integrate MCP servers, this one has a hard dated deadline. The release candidate is available now, and the final spec is locked to July 28. That leaves less than four weeks to validate against the RC and plan your migration. This guide is the decision-intent version: what the spec is, what actually breaks, what is worth adopting, and a concrete checklist split by role so you can figure out how urgent this is for your setup.

For the deep code-level walkthrough of the transport change specifically, see the companion MCP stateless migration guide. This post is the wider map.

What the 2026-07-28 Spec Actually Is

MCP has shipped dated specification versions since launch. Each version is a snapshot of the protocol that clients and servers negotiate against. The 2026-07-28 version consolidates a year of roadmap work (the 2026 roadmap) into a single dated release, and it is intentionally a clean break rather than a gentle addition.

Three things make it a big deal:

1. It changes the transport contract. A stateless core means the shape of a valid request and response is different, so old and new implementations do not silently interoperate.
2. It deprecates features that many servers and clients rely on today. Deprecation starts a removal clock, so code that works now becomes tech debt on a schedule.
3. It ships governed extensions. Instead of the protocol growing forever, optional capabilities now live in versioned extensions with their own lifecycle, following the SEP change process.

The net effect: fewer things live in the mandatory core, the core is simpler and easier to scale, and the interesting new surface area moves into extensions you opt into.

What Breaks

The stateless core

The headline change is that the core protocol goes stateless. The old model required a session: the client connected, sent an initialize message, received a session identifier, and echoed that identifier on every following request. That session pinned a client to one server instance.

The new core drops the session handshake. Each request is self-contained and can hit any server instance, so an MCP server can run behind a plain round-robin load balancer with no sticky sessions and no shared session store. Routing moves to an Mcp-Method header, so gateways can make routing decisions from headers instead of parsing request bodies. And tools/list responses become cacheable through a ttlMs field, so clients and infrastructure can hold the tool list for a defined window instead of refetching it on every connection.

The practical impact on existing code:

Any server that expects initialize as the first message, any gateway that routes on a session header, and any client that assumes a pinned instance will need to change. The upside is real: horizontal scaling, serverless deployment, and edge compute all get much simpler once state leaves the core. The deeper code patterns for externalizing state are covered in the stateless migration guide.

Deprecated: Roots, Sampling, and Logging

The spec deprecates three features that shipped in earlier versions:

• Roots - the mechanism for a client to advertise filesystem or workspace boundaries to a server.
• Sampling - the mechanism for a server to ask the client's model to generate a completion on its behalf.
• Logging - the protocol-level logging notifications servers emit to clients.

Deprecation is not deletion. Per the SEP guidelines, deprecated features enter a formal lifecycle rather than disappearing on release day, which is the maintainers' answer to the criticism that breaking changes used to arrive with no runway. But the direction is set: if your server relies on Sampling to call back into the host model, or your client leans on Roots to scope a server, or you depend on protocol Logging for observability, you are now building on features with an expiration date. Plan replacements. For observability, the spec's standardized tracing keys (below) are the forward path instead of protocol Logging.

Stricter tool schemas: full JSON Schema 2020-12

Tool input schemas move to full JSON Schema 2020-12. If your tools currently use a loose subset of JSON Schema, or rely on validator quirks, stricter validation can reject schemas that used to pass. This is a good change for correctness and for how reliably a model can call your tools, but it is a real compatibility checkpoint. Validate every tool schema against a 2020-12 validator before you ship.

What Is New and Worth Adopting

The rewrite is not only subtraction. Several additions are worth adopting deliberately.

MCP Apps: server-rendered UIs

MCP Apps lets a server return sandboxed, server-rendered UI instead of only text. A tool can hand the host a real interface - a form, a table, a control panel - that the client renders in a contained surface. This is the biggest expansion of what a tool call can return, and it changes the design space from "return a string" to "return an interaction." If your product would benefit from richer output than markdown, this is the feature to prototype first.

Tasks as a first-class extension

Long-running work gets a proper home. Tasks graduates from experimental into a first-class extension for operations that do not finish inside one request: builds, deployments, long agent runs, batch jobs. Because the core is now stateless, Tasks is built around resumable, pollable state rather than a held-open connection, so any server instance can report on or advance a task as long as it can reach the shared task store. If you shipped against the earlier experimental Tasks surface, budget time to migrate to the extension's model.

Auth hardening: OAuth and OIDC

Authorization gets stricter and more standards-aligned around OAuth and OIDC. The direction is tighter validation of tokens and issuers and cleaner client registration, which matters because MCP servers increasingly sit in front of real systems and real data. If you run any authenticated server, treat the auth section of the RC as required reading rather than a nice-to-have, and test your token validation against it directly.

Standardized tracing

Distributed tracing keys are standardized across SDKs, so requests can be traced across a chain of MCP servers with a common context. With protocol Logging deprecated, this is the sanctioned observability path. Wire it in as you migrate.

Migration Checklist: Server Authors

Work top to bottom. The early items are the ones that break interoperability.

• Read the RC. Start from the 2026-07-28 release candidate and note every capability your server implements today.
• Remove the initialize handshake path. Stop requiring a session as the first message. Treat every request as self-contained.
• Externalize any session state. Move per-session memory into an external store (or drop it) so any instance can serve any request. See the stateless guide for patterns.
• Support Mcp-Method header routing. Make sure your server and any gateway in front of it route on headers, not body inspection or a session ID.
• Add ttlMs to tools/list. Declare how long your tool list is cacheable so clients and infra stop refetching it.
• Validate tool schemas against JSON Schema 2020-12. Fix anything a strict validator rejects.
• Audit Roots, Sampling, and Logging usage. Find every place you depend on them and plan replacements before their lifecycle ends.
• Harden auth. Bring OAuth/OIDC token and issuer validation in line with the RC. Do not ship an authenticated server on the old rules.
• Migrate Tasks. If you had long-running operations, move them onto the Tasks extension with resumable state.
• Adopt standardized tracing. Replace protocol Logging with the standardized trace context keys.
• Evaluate MCP Apps. If richer output helps your product, prototype a server-rendered surface.
• Test against the RC and confirm your SDK's support. Do not assume your SDK version already speaks 2026-07-28.

Migration Checklist: Client and Host Integrators

If you build the agent, IDE, or host that connects to MCP servers, your job is different: you decide which spec versions to negotiate and how gracefully you degrade.

• Stop sending initialize as a required step. Issue self-contained requests against 2026-07-28 servers.
• Do not assume a pinned server instance. Design for any request reaching any instance behind a load balancer.
• Honor ttlMs on tools/list. Cache the tool list for the declared window instead of refetching per connection.
• Update your auth flow. Align client registration and token handling with the hardened OAuth/OIDC requirements.
• Plan for deprecated capabilities. If your host relies on Roots, Sampling, or Logging, build the replacement path now.
• Add MCP Apps rendering, safely. If you will surface server-rendered UI, render it in a sandbox and treat it as untrusted.
• Support Tasks polling. Handle long-running operations through the Tasks extension's resumable model.
• Decide your compatibility window. For an established user base, negotiate both the old and new versions through a transition period rather than cutting over overnight.
• Read the security guidance. Fold the NSA/DoD recommendations into how your host trusts and isolates servers.

Who Is Affected and How Urgent

Not everyone needs to move at the same speed. Use this to triage.

The blunt version: if you maintain session state or run authenticated servers, treat this as high priority with less than four weeks of runway. If your server is already stateless and unauthenticated, you have more slack, but you still need to validate against the RC and update your SDK.

Security Context

The timing matters. On June 2, 2026, the NSA and DoD published security guidance for MCP. When defense agencies publish protocol-specific guidance, it is a signal that MCP is now load-bearing infrastructure connecting agents to real systems, and that the threat model deserves attention.

Read the two together. The 2026-07-28 auth hardening and the security guidance point the same direction: MCP servers sit in front of sensitive data and actions, so authorization, isolation, and trust boundaries are now core engineering concerns, not afterthoughts. If you adopt MCP Apps, remember that server-rendered UI is untrusted content and must be sandboxed. Migrating is the moment to also close security gaps, not just chase the spec.

Frequently Asked Questions

When does the 2026-07-28 MCP spec take effect?

The final specification is dated July 28, 2026. The release candidate is available now, so the window between the RC and the final date is your validation and migration runway. As of early July that is less than four weeks.

Is this really the biggest MCP change since launch?

The maintainers describe it as the largest revision since launch, and the scope backs that up: a rewritten stateless core, three deprecated features, stricter tool schemas, hardened auth, and two graduated extensions in one dated release. See the release candidate announcement.

What breaks if I do nothing?

Servers that require the old initialize handshake will not interoperate cleanly with clients that speak 2026-07-28, and vice versa. Gateways that route on a session ID, tool schemas that only pass loose validation, and authenticated flows on the old rules are the most likely to fail. Features you built on Roots, Sampling, or Logging keep working for now but are on a removal clock.

Are Roots, Sampling, and Logging removed immediately?

No. They are deprecated, which starts a formal lifecycle rather than deleting them on release day, per the SEP guidelines. Treat deprecation as a scheduled removal and plan replacements now instead of waiting for the cutoff.

Do I have to adopt MCP Apps and Tasks?

No. They are extensions you opt into, not mandatory core. Adopt MCP Apps if richer server-rendered output helps your product, and adopt Tasks if you run long-running operations. The stateless core is the part everyone must reckon with; the extensions are opportunistic.

What is the fastest safe migration order?

Fix interoperability first (drop the initialize requirement, externalize state, support header routing), then correctness (validate schemas against JSON Schema 2020-12), then security (harden OAuth/OIDC), then adopt extensions. The role-specific checklists above are ordered that way.

Where is the code-level detail for the stateless change?

The companion MCP stateless migration guide walks through the transport change with before-and-after code, including how to externalize session state for horizontal scaling.

Sources

• MCP 2026-07-28 Release Candidate announcement
• 2026 MCP Roadmap
• MCP SEP guidelines (specification change process)
• NSA/DoD MCP security guidance (PDF)
• JSON Schema 2020-12 specification