MCP Roadmap 2026: What Changed, What Breaks, What Is Next

The MCP roadmap, as of October 2026, targets five areas: async work and server push, a single HTTP-native transport, agent identity for enterprise security, a cleaner tool-result shape, and better SDKs. The biggest change already shipped. The 2026-07-28 specification gave MCP a stateless core by removing the startup handshake and protocol-level sessions.

That release breaks compatibility in both directions between old and new clients and servers. Below: what each revision changed, what comes next, and a pass/fail upgrade checklist for production MCP servers. New to the protocol? Start with what MCP is.

What is on the MCP roadmap right now?

The official MCP roadmap, last updated August 22, 2026, “reflects current thinking rather than firm commitments.” Proposals inside its five areas get expedited review:

1. Agentic messaging primitives. Tasks, subscriptions/listen, and progress notifications grew up in separate working groups. The risk: “three answers to ‘the server isn’t done yet’” with no shared lifecycle. Next: server push, including webhooks, and moving Tasks toward the core protocol.
2. HTTP-native transport. SDKs maintain separate HTTP and stdio pipelines today. The plan is Streamable HTTP as the only binding, run over stdin and stdout for local servers, plus ETag caching.
3. Agent identity and enterprise security. The roadmap admits MCP auth “assumes a person with a browser at consent time,” while servers “lean on pasted API keys and long-lived refresh tokens.” Work items: DPoP, workload identity federation, the ID-JAG grant behind Enterprise-Managed Authorization, and RFC 8693 token exchange.
4. Improved primitives. tools/call can return content and structuredContent together, which the roadmap says produced diverging implementations. A redesign is planned, plus progressive discovery of tools.
5. SDK developer experience. Generating a Tier 1 SDK from the spec, tested against the conformance suite.

Decision rule: treat a roadmap item as unavailable until it appears in a dated spec revision, or in an official extension your clients support. Plan against changelogs, not the roadmap.

MCP spec revisions: the timeline

MCP ships dated revisions, and older ones stay published. The table covers every revision after the original 2024-11-05 release, plus the governance change. The last column is my recommendation for production teams.

Auth changed in every revision; the 2026-07-28 release notes say “authorization is where implementers spend most of their integration time.”

What changed in 2026-07-28, and what it breaks

Before, a client opened with an initialize handshake, and an HTTP server could return an Mcp-Session-Id for every later request to carry. That pinned the client to one instance, so scaling out meant sticky routing or a shared session store. SEP-2575, the proposal behind the change, calls that load-balancing problem “the most critical issue.”

2026-07-28 removes both. Every request carries its protocol version and client capabilities in _meta. Servers must implement server/discover for clients that want capabilities up front. Over HTTP, the method and tool name ride in Mcp-Method and Mcp-Name headers, so a gateway can route without parsing JSON. Server-to-client requests such as elicitation use Multi Round-Trip Requests: the server returns resultType: "input_required", and the client retries the call with answers attached. ping and SSE stream resumability are gone.

The failure mode is version skew. The spec’s compatibility matrix is blunt: a legacy client calling a modern-only server fails, and so does a modern-only client calling a legacy server. Legacy clients “have no fall-forward mechanism.” A dual-era server speaks both, on the same endpoint, and works with everyone.

Decision rule: if you do not control every client that calls your server, run it dual-era. Drop legacy support only after your logs show zero initialize calls for a full client release cycle.

Early detection: log the MCP-Protocol-Version header per request and chart it by client name.

Auth: from OAuth 2.1 to agent identity

The current authorization spec makes a protected MCP server an OAuth 2.1 resource server. Three rules matter most.

Audience binding. Clients must send an RFC 8707 resource parameter naming the server’s canonical URI in both the authorization and token requests. Servers must validate that each token was issued for them, and “MUST NOT accept or transit any other tokens.” The security best practices explain the passthrough ban: downstream logs show the wrong identity, and a stolen token works anywhere it is accepted.

Issuer validation. Since 2026-07-28, clients must compare a returned iss value against the issuer they recorded before redirecting, per RFC 9207. This blocks mix-up attacks, where a malicious authorization server obtains a code issued by an honest one. A future revision is expected to make iss mandatory, so emit it now.

Registration. Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents, where the client ID is an HTTPS URL.

Statelessness adds a failure mode. Servers now keep cross-call state in handles passed as tool arguments, and state handle hijacking means someone guesses or steals a handle and acts on another user’s state. Servers “MUST NOT treat possession of a state handle as authentication” and should key state as <user_id>:<handle>, with the user ID from the verified token. SEP-2575 states the rule: every request is authenticated and authorized on its own.

Agent identity comes next. Until it lands, give each agent its own non-human identity and centralize policy in an MCP gateway. For tool poisoning, see the MCP security guide.

Long-running work, elicitation, and structured output

Three features have each been reshaped at least once.

Tasks. Tasks arrived as an experimental core feature in 2025-11-25 for “tracking durable requests with polling and deferred result retrieval.” In 2026-07-28 they moved into an official extension, io.modelcontextprotocol/tasks. Polling with tasks/get replaced the blocking tasks/result, tasks/update carries client input, and tasks/list was removed. Code built on the experimental API has to migrate. Push already exists for tasks: per the Tasks extension docs, servers can send notifications/tasks on a subscriptions/listen stream, though polling is the default. What the roadmap still lists as open is broader server-initiated events, including webhooks.

Elicitation. Servers could ask users for input from 2025-06-18, with URL mode for out-of-band interactions added in 2025-11-25. In 2026-07-28 delivery moved to Multi Round-Trip Requests, and the elicitationId field and completion notification from 2025-11-25 were removed eight months after they shipped.

Structured output. Added in 2025-06-18. In 2026-07-28, outputSchema opened up to full JSON Schema 2020-12, and structuredContent can be any JSON value. Next, the roadmap plans to redesign tools/call itself.

The production risk is quieter. The 2026-07-28 changelog says “a broken response stream loses the in-flight request,” and the client must re-issue it with a new request ID. If your server finished a side effect before the stream broke, the retry can do it twice.

Decision rule (mine): any tool that writes, pays, or sends takes an idempotency key, and the server ignores repeats of a key it has already seen. A Task ID does not replace that key. The server creates the task before the client receives the handle, so a lost creation response plus a resubmit can start a second task. Deduplicate task creation and the side effect itself. For retry-safe tool design, see AI agent tool design. Keep result building in one function per tool, so the coming tools/call redesign is one edit.

Scaling, caching, and discovery

Any request “can now land on any server instance behind a plain round-robin load balancer without needing shared storage,” per the release notes.

Cache hints. List results and resource reads must now return ttlMs, a freshness hint in milliseconds, and cacheScope, either public or private. Servers should also return tools in a deterministic order, which the changelog ties to better LLM prompt cache hit rates.

Hypothetical example: 40 agent instances run 2,000 tasks an hour and call tools/list before each one, so 2,000 list calls without caching. Assume each instance keeps one cache entry, honors a ttlMs of 300,000 (five minutes), and sees no invalidation or restart during the hour. Then each instance fetches at most 12 times an hour, so the fleet makes at most 40 × 12 = 480 calls, 76% fewer. At 10,000 tasks an hour the bound is still 480, 95.2% fewer. ttlMs is a freshness hint, not a request limit: a list_changed notification, a restart, or separate per-user entries add fetches. If an instance’s requests arrive more than five minutes apart, every call misses.

The failure mode is cacheScope, which controls whether shared intermediaries may cache a response. If your tool list varies by user, mark it private, or a shared cache can serve one user’s list to another.

Header trust and traces. Servers must reject requests whose routing headers disagree with the body. Per the Streamable HTTP spec, gateways enforcing policy on those headers should reject older or missing protocol versions rather than trust unvalidated values. Trace context keys in _meta are now documented, which helps agent observability from client to downstream calls.

Discovery. The official MCP Registry is still in preview, and “breaking changes or data resets may occur.” It verifies namespaces through GitHub, DNS, or HTTP challenges, but leaves security scanning to package registries and downstream aggregators. Treat a listing as provenance, not approval.

Who decides what comes next?

On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation. Anthropic, Block, and OpenAI co-founded it, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg.

For production teams, the change that matters most is the 2026-07-28 feature lifecycle policy. A deprecated feature stays in the spec for at least twelve months, counted from the release of the revision that deprecated it. Tier 1 SDKs must mark deprecated APIs in their next release and should warn at runtime. So Roots, Sampling, and Logging, deprecated on July 28, 2026, can be removed no earlier than a revision released on or after July 28, 2027.

Decision rule: build production servers on a Tier 1 SDK (TypeScript, Python, Go, or C#). The policy obliges those SDKs to surface deprecations, so a CI run that fails on deprecation warnings is your early warning system.

Upgrade checklist for production MCP servers

Run these against staging before you call a server 2026-07-28 ready. New to building servers? Start with the MCP server build guide.

For test 11, the changelog suggests: tool parameters or server config instead of Roots, direct LLM provider APIs instead of Sampling, and stderr or OpenTelemetry instead of Logging. If you relied on Mcp-Session-Id, move that state into handles and pass test 7 first.

Bottom Line

MCP now has a stateless core: easier to scale over HTTP, easier to break during migration.

Run dual-era until your logs say otherwise. Bind every token to its server and every handle to its user.

Plan against dated revisions, not the roadmap. Next step: run the 11 tests against staging this week.

FAQ

What is the latest MCP specification version?

2026-07-28, released July 28, 2026. All four Tier 1 SDKs supported it on release day.

Who owns MCP now?

The Agentic AI Foundation, a directed fund under the Linux Foundation. MCP joined Block’s goose and OpenAI’s AGENTS.md as its founding projects. Anthropic still contributes.

Is MCP fully stateless after 2026-07-28?

Not entirely. SEP-2575 calls it stateless by default, and a subscriptions/listen request still holds one long-lived stream for change notifications. Your application can keep state too, in explicit handles rather than the transport.

Can a deprecated MCP feature be removed faster than twelve months?

Yes, but only for an active security risk with a published advisory or documented exploitation and no in-place fix. Even then, the policy requires at least ninety days between deprecation and earliest removal, and core maintainers must approve it.

Can I publish internal MCP servers to the official MCP Registry?

No. It only lists servers whose package or endpoint is publicly reachable. The official registry codebase is not designed for self-hosting, so use a private registry that implements its published OpenAPI spec.

When is the next MCP spec release?

The roadmap gives no date. It covers the next six to twelve months and warns that items may be delivered differently or deferred. Plan upgrades from dated revisions only.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect