What the MCP 2026 Roadmap Means for Your Infrastructure¶
The final 2026-07-28 MCP specification ships in two weeks. The release candidate has been locked since May 21st, which means the ten-week validation window the maintainers gave SDK authors and client implementers is almost up. If you're running MCP servers in production and haven't looked at what's actually in this release, that's the deadline you're working against, not some vague "sometime this year" future.
We already covered the headline change, the stateless protocol core, in a dedicated deep dive with the Kubernetes routing details. This post is about the rest of the release: what's shipping alongside statelessness, what's deprecated but not gone, and, more usefully, which of these changes need action from you before July 28 and which don't.
The date that actually matters
May 21 was the release candidate lock. July 28 is when 2026-07-28 becomes the specification, breaking changes and all. Tier 1 SDKs are expected to ship support inside that window. If your MCP client or server pins to a specific spec version, this is the release where pinning stops being optional.
What's actually in this release¶
Six Specification Enhancement Proposals do the work of removing protocol-level sessions. On top of that, the release adds a formal Extensions framework, ships two official extensions (MCP Apps and a redesigned Tasks), hardens authorization against how OAuth 2.1 and OpenID Connect actually get deployed, deprecates three core primitives, and lifts tool schemas to full JSON Schema 2020-12. It's the largest revision since the protocol launched, and it's landing as one release rather than trickling out over the year.
That's a lot to absorb in one spec bump, which is exactly why the maintainers paired it with a formal deprecation policy: nothing in this release breaks silently, and nothing after it will either, if the policy holds.
Authorization hardening: six SEPs that change how you configure OAuth¶
This is the part with the shortest fuse, because it changes what your authorization server needs to be doing right now, not just what your MCP client and server need to support by July 28.
Clients must validate the iss parameter on authorization responses per RFC 9207. It's a mitigation for a mix-up attack that's more likely in MCP's deployment pattern specifically — one client, potentially many servers, potentially many authorization servers behind them. The spec doesn't require clients to reject a response missing iss yet, but that's where it's headed:
# What this means for your auth server config today:
# start returning `iss` on every authorization response,
# even though rejection-on-missing isn't mandatory yet
authorization_response:
iss: "https://auth.yourplatform.io" # RFC 9207 — add this now
code: "..."
state: "..."
Five more SEPs round out the hardening: clients now declare application_type during Dynamic Client Registration so an authorization server stops defaulting a CLI tool to "web" and rejecting its localhost redirect URI, registered credentials bind to the issuing authorization server and re-register on migration, refresh token requests against OpenID Connect-style servers are documented, scope accumulation during step-up auth is clarified, and the .well-known discovery suffix is nailed down.
None of this requires you to rewrite an MCP server. It requires you to check whether the authorization server sitting in front of it, the one issuing tokens for your MCP fleet, already does these things. If you're running Enterprise-Managed Authorization for your MCP servers, this is the layer underneath it: EMA handles who gets to connect, this hardening closes off the specific attacks against how that connection gets negotiated.
Roots, Sampling, and Logging are deprecated, not removed¶
Three core primitives lose Active status in this release, under the new feature lifecycle policy:
| Feature | Replacement |
|---|---|
| Roots | Tool parameters, resource URIs, or server configuration |
| Sampling | Direct integration with LLM provider APIs |
| Logging | stderr for stdio transports, OpenTelemetry for structured observability |
The deprecation window is a floor, not a deadline
The new lifecycle policy guarantees at least twelve months between a feature being marked Deprecated and it becoming eligible for removal, and removal itself needs a separate SEP. If your MCP servers use Sampling or Logging today, they keep working in 2026-07-28 and in every spec version published within a year of it. There's no July 28 fire drill here — just a clock that's now started.
The practical move is to plan the migration, not rush it. Logging maps cleanly onto whatever OpenTelemetry pipeline you're already running for the rest of your platform, which is worth doing anyway since it gets MCP server logs into the same trace context as everything else. Sampling going away pushes model calls back into direct provider API integration, which most teams running MCP in production were already doing around the primitive rather than through it.
Extensions become first-class, and that changes how you adopt new capability¶
Before this release, extensions existed but had no formal process. Now they get reverse-DNS identifiers, their own ext-* repositories with delegated maintainers, and version numbers that move independently of the core spec. Clients and servers negotiate which extensions they support through an extensions map, rather than everything being bundled into whatever the next spec version happens to ship.
Two extensions launch alongside 2026-07-28. MCP Apps lets servers ship interactive HTML interfaces that render in a sandboxed iframe on the client — tools declare their UI templates ahead of time so a host can prefetch and security-review them before anything executes, and every UI-initiated action still goes through the same audit and consent path as a direct tool call. Tasks, which shipped experimental in 2025-11-25, graduates to an extension with a redesigned lifecycle: a server answers tools/call with a task handle, and the client drives it forward with tasks/get, tasks/update, and tasks/cancel. tasks/list is gone entirely, because it can't be scoped safely without the sessions this release just removed.
If you built against the experimental Tasks API
Anyone running long-running MCP tool calls against the 2025-11-25 Tasks primitive needs to migrate to the new extension lifecycle. Polling replaces the old blocking model, and task creation is now server-directed: the client just advertises support and the server decides what runs as a task.
The bigger shift is what this does to how you adopt new MCP capability going forward. A capability shipping as an extension means you can pick it up when it's useful to you, independent of whether you've moved to the latest core spec version. That's a meaningfully different adoption model than the all-or-nothing spec bumps MCP has shipped until now.
The enterprise readiness gap the roadmap admits it hasn't closed¶
The March 2026 roadmap named four priority areas: transport scalability, agent communication, governance maturation, and enterprise readiness. The first three are substantially addressed in 2026-07-28. The fourth isn't, and the roadmap says so directly — enterprise readiness is "the least defined of the four priorities," there's no dedicated Working Group for it yet, and the specific gaps it names are audit trails, SSO-integrated auth, gateway and proxy behavior, and configuration portability.
That list should look familiar if you've been building MCP infrastructure ahead of the spec rather than waiting for it. Structured audit trails that plug into existing SIEM and APM tooling, enterprise-managed auth with SSO-integrated flows, gateway patterns for authorization propagation — these are exactly the gaps Enterprise-Managed Authorization and a self-hosted operator like ToolHive already close at the platform layer, not the protocol layer. The maintainers expect most of this enterprise work to land as extensions rather than core spec changes, specifically so the base protocol doesn't get heavier for everyone who doesn't need it. If you're already running policy enforcement, audit logging, and managed auth in front of your MCP fleet, you're not behind this part of the roadmap. You're the reason it gets to stay optional for everyone else.
What to build now versus what to wait for¶
Build now, regardless of July 28: audit logging that routes MCP tool invocations through your existing OTel pipeline, least-privilege token scoping per tool rather than per server, and an enterprise auth pattern in front of your MCP fleet if you don't have one. None of this needs the new spec — it needs the same platform-engineering discipline you'd apply to any other production service.
Validate before July 28: whether your gateway or load balancer routes on request bodies instead of the new Mcp-Method and Mcp-Name headers, whether your authorization server returns iss on authorization responses, and whether anything in your stack pattern-matches on the old -32002 missing-resource error code that's now the standard JSON-RPC -32602.
Actually wait for: a dedicated Enterprise Working Group and whatever extension eventually formalizes audit trails and config portability at the protocol level. Building your own version now, on infrastructure you control, isn't a stopgap — it's very likely closer to what the extension ends up looking like than anything you'd get by waiting.
FAQ¶
Do I need to migrate to the stateless model before July 28?
If you're running Streamable HTTP in production, yes — the session handshake and Mcp-Session-Id header are removed in this release, not deprecated. See the stateless deep dive for the Kubernetes-specific migration path.
Will my MCP server break if it still uses Sampling or Logging?
No. Both are deprecated, not removed, and the new lifecycle policy guarantees at least twelve months before anything deprecated becomes eligible for removal. Plan the migration; don't rush it for July 28.
Does the authorization hardening require code changes in my MCP server?
Not directly. The six SEPs mostly change what your authorization server needs to do — returning iss, handling application_type correctly, binding credentials to the issuing server. Check your auth server config before you check your MCP server code.
What's the actual difference between this and the stateless RC post you published in May?
That post is the deep dive on the transport and routing changes specifically, with working Kubernetes Gateway API examples. This one covers the rest of the release (authorization, deprecations, extensions, and the enterprise readiness gap) and is written for the "what do I need to do before July 28" decision, not the implementation detail.
Where does audit logging and enterprise auth actually land in the spec?
Nowhere yet, officially. The roadmap flags it as the least-defined of the four priority areas with no dedicated Working Group as of this writing, and expects most of it to ship as extensions rather than core spec changes. If you need it now, build it at the platform layer. That's not a workaround; it's the same shape the extension will likely take.
Two weeks isn't long, but almost none of what's actually landing on July 28 requires you to do anything differently on that specific day. The stateless migration was already your job in May. The authorization hardening is mostly your auth server's job, not your MCP server's. The deprecations have a twelve-month floor under them. The one genuinely open question, enterprise readiness, doesn't have a spec answer yet — which means the platform teams who built their own answer aren't behind the roadmap. They're ahead of it.