MCP spec 2026-07-28 changes: what breaks and how to migrate

The biggest MCP spec 2026-07-28 changes are that the protocol is now stateless: sessions and the initialize handshake are gone, and every request describes itself. The release, published July 28, 2026, also deprecates Roots, Sampling and Logging, moves tasks into an extension and tightens authorization. If you run MCP servers or clients in production, plan a migration: a client that only speaks the new version cannot talk to an old server.

What MCP is, in one paragraph

The Model Context Protocol is an open standard for connecting AI assistants and agents to external tools and data. An MCP server exposes tools (look up an order, open a ticket) and resources, and any compatible client (an IDE, an assistant, your own agent) can use them without a custom integration for each one. Since December 2025 the project sits in the Agentic AI Foundation under the Linux Foundation, with technical decisions still made by its maintainers. It is the piece we reach for when we connect AI to a company's systems. To try it yourself, here is how to add an MCP server to Claude Code.

MCP spec 2026-07-28 changes at a glance

Compared with the previous revision (2025-11-25), the official changelog lists:

• No sessions. Protocol-level sessions and the Mcp-Session-Id header are removed. When you need state across calls, the server mints an explicit handle and the client passes it back as an ordinary tool argument.
• No handshake. initialize and notifications/initialized are gone. Each request carries the protocol version and client capabilities in _meta, and modern servers must implement server/discover.
• Servers stop asking on their own. roots/list, sampling/createMessage and elicitation/create are no longer server-to-client requests. The server returns an input_required result and the client retries with the answers (Multi Round-Trip Requests).
• One notification stream. subscriptions/listen replaces the HTTP GET endpoint and resources/subscribe. SSE resumability is removed: if a stream drops, the client issues it again as a new request.
• New HTTP headers. Streamable HTTP POST requests carry Mcp-Method and Mcp-Name, which makes routing and filtering at a load balancer or gateway much easier.
• Tasks become an extension. Long-running tasks move to io.modelcontextprotocol/tasks, with polling through tasks/get instead of a blocking call.
• Explicit caching. List and read results declare how long they can be cached (ttlMs) and for whom (cacheScope).
• Tracing. The spec documents how to propagate OpenTelemetry context (traceparent, tracestate, baggage) in _meta. It is a documented convention, not a new requirement.

What is deprecated

Roots, Sampling and Logging are deprecated. They keep working through the deprecation window (at least 12 months under the new feature lifecycle policy), but new implementations should not adopt them. The suggested replacements: pass directories or files as tool parameters instead of Roots, call your model provider's API directly instead of Sampling, and log to stderr or OpenTelemetry instead of Logging. The HTTP+SSE transport, deprecated since 2025-03-26, now falls under the new lifecycle policy.

Tighter authorization

• Authorization servers should send iss (RFC 9207), and clients must validate it when it is present.
• Credentials are bound to the authorization server that issued them and must not be reused with another one.
• Dynamic Client Registration (DCR) is deprecated in favor of Client ID Metadata Documents (CIMD); DCR stays available for backward compatibility.

What it means if you run MCP servers in production

The upside is operational. A server without sessions can sit behind a plain load balancer, scale across instances or run serverless with no sticky sessions: any instance can answer any request. The new headers and explicit caching also make it easier to put a gateway in front.

The cost is compatibility across eras. Per the versioning page's matrix, two modern implementations work together without trouble. When client and server are on different eras, it only works if one side is "dual-era" and speaks both: a modern-only client fails against a legacy server, and a legacy client fails against a modern-only server, because legacy clients have no way to fall forward.

All four Tier 1 SDKs (TypeScript, Python, Go and C#) support the new version. Watch for renames: the Python mcp package moved to version 2 and FastMCP is now MCPServer; the TypeScript SDK split into @modelcontextprotocol/server and @modelcontextprotocol/client, with a codemod for the upgrade.

Migration checklist

1. Inventory. List your MCP servers and clients, the SDK version of each, and who consumes them (internal teams, customers, third-party tools).
2. Find session dependencies. Any logic that reads Mcp-Session-Id or keeps per-connection state needs to move to explicit handles in tool arguments.
3. Check Roots, Sampling and Logging. If you use them, schedule the replacement inside the 12-month window.
4. Upgrade the SDK to a release that supports 2026-07-28 and follow its official migration guide.
5. Pick a compatibility strategy. If you don't control every client, run your server dual-era during the transition.
6. Review authorization. iss validation, issuer-bound credentials and, if you register clients dynamically, the move to CIMD.
7. Test with the real client your teams use (the IDE or assistant), not only unit tests.
8. Observe. Use trace propagation to follow one call from the agent all the way into your system.

What it means for a company wiring AI into its systems

If your company connects assistants or agents to its ERP, CRM or databases through MCP, this is not a fire drill for tomorrow, but it belongs on next year's roadmap: the new SDKs have stable releases (Python's mcp 2.0.0 shipped on July 28) and the deprecated features have a deprecation window of at least 12 months. It is also a good moment to review what each exposed tool is allowed to do, since the migration means touching that code anyway.

If you want us to review your MCP servers or design the integration from scratch, get in touch. Our senior team in Latin America works remotely with companies in the US, Canada and Europe.