“The largest revision of the protocol since launch.”
That’s the MCP team on the new spec, version 2026-07-28, shipping July 28, 9 days from now. It’s a locked release candidate today (the current spec is 2025-11-25), and SDK maintainers have been validating against it for ten weeks.
Before you panic-audit anything, separate two questions:
If your server implements the current spec and works with your target clients, July 28 does not switch it off and does not force a migration. Your MCP servers are safe. As of July 19, the mainstream clients all still speak legacy MCP, and no modern-only cutover has been announced anywhere I can find.
Adopting 2026-07-28 is a different story: it’s a breaking revision for implementations that move to it. The initialization handshake and protocol session go away, several RPCs are removed or replaced, and the experimental Tasks API moves out of core. There is a new deprecation registry but it does not apply to previous versions.
So what’s important to you? I’ve picked seven features that matter if you build MCP servers, and the three extensions you should know about. The full changelog has every change.
The changes you should care about:
1. Stateless core (SEP-2567, SEP-2575)
The protocol-level session is gone. The initialize handshake is gone. The Mcp-Session-Id header is gone. Every request now carries its protocol version and capabilities, and cross-call state becomes explicit handles your server mints and accepts as ordinary tool arguments.
What’s new: your server runs behind plain HTTP load balancers. No sticky sessions, serverless-friendly, cheaper to operate. Theoretically fewer issues on the client side too.
2. Official extensions
Extensions are now a first-class part of the protocol: SEP-2133 creates the framework, with an extensions field in client and server capabilities and an official-extension track. MCP Apps (SEP-1865) give your product real UI inside the conversation, standardizing the patterns pioneered by MCP-UI and the OpenAI Apps SDK. Tasks (SEP-2663) give long-running work durable handles, redesigned on its way out of the experimental core. Neither one is new. What’s new is the official status.
3. Discovery (SEP-2575)
Your server declares up front which spec versions it speaks and what it can do, with one server/discover call. Clients stop guessing. New in this release, and required: servers MUST implement it, clients MAY call it (or just send their preferred version and retry if they get a version error).
4. Change notifications (SEP-2575)
Clients subscribe with one subscriptions/listen call and get told when your tools, prompts, or resources change. The notification types existed before. What’s new is one explicit, opted-in subscription stream replacing the old GET path and resource subscribe calls. If you manage more than one server, this is the change-management primitive you’ve been missing.
5. Caching, by spec (SEP-2549)
Results from list and read calls now carry freshness hints (ttlMs) and a cache scope. Servers should also return tools in deterministic order, and the spec says why: LLM prompt cache hit rates. Cheaper agent sessions, written into the standard.
6. Hardened auth (SEP-2468, SEP-837, SEP-2352)
Authorization is built on OAuth 2.1, and this release aligns it more closely with how OAuth and OpenID Connect are deployed in practice: issuer validation, application_type declarations, credentials bound to the issuing server. (The authorization framework itself stays optional, defined for HTTP transports.) And client registration moves from DCR to CIMD (PR 2858), with DCR deprecated but kept for backwards compatibility.
7. A feature lifecycle (SEP-2596)
Every feature is now Active, Deprecated, or Removed, tracked in a public registry, and nothing gets removed with less than 12 months notice. Roots, Sampling, and Logging are Deprecated with this release, with earliest removal on or after July 28, 2027. You can plan around MCP now.
The three extensions worth knowing:
- MCP Apps (SEP-1865): interactive UI, rendered inline in the conversation. Your product shows UI inside a chatbot, not just tools and text.
- Tasks (SEP-2663): asynchronous work with durable handles. Poll with tasks/get, feed input with tasks/update, cancel with tasks/cancel. Once a client advertises the extension, a server can answer any eligible call with a task instead of a result, no per-call flag needed.
- Enterprise-Managed Authorization (SEP-990): IT approves your server once, authorized users sign in with SSO, with one audit trail. This one shipped in June, separate from the spec release, and Okta, Claude, VS Code, Asana, Atlassian, Figma, and Linear are already on it.
One more incubating in the community: Skills over MCP, a working group on structured instructions for agent workflows, discovered and consumed through MCP. Worth watching.
What you need to do:
- If you publish an SDK or build/eval tooling: support the new version fast. The validation window has been running since May.
- If you run an MCP server: you’re fine for now. Adopt when one of the seven above is something you need, or when a client you depend on announces modern-only support.
- For hosts (Claude, ChatGPT, the IDEs): they own the cutover dates. As of July 19, none are announced.
P.S. - I run a live hands-on workshop, Build an MCP Product with AI. We’ll dissect MCP, talk about the all-important metadata, build two servers under the current spec, learn evals, then finally compare distribution paths and walk through the spec change. All in 4 hours.