MCP maturity in October 2026: what’s stable, what’s deprecated, what’s still a bet

October 24, 2026 · Part 3 of 4

A vendor’s roadmap for a Model Context Protocol (MCP) server will mention MCP Apps, Tasks, Skills, maybe interceptors. Some of those are stable, one is a draft, and some are proposals that may change or disappear. What I’d want, before I plan around any of them, is a map: which revision of the specification the server speaks, what that revision removed, how long a deprecated feature keeps working, and where each extension stands. Here it is, as of October 2026.

This is part 3 of a short series for the people who buy, approve and govern MCP servers rather than build them, after part 2’s governance checklist. It draws on the same facts as my series for builders, under the 2026-07-28 specification, as I read them in October 2026. Where something is my advice, I say so.

MCP is an open standard that lets AI applications discover and use external tools, data and prompt templates through one common interface. Its specification is versioned by date, and that date is the first thing to read in any vendor’s claim.

In brief

1. There have been five revisions since November 2024, named by date, and the fifth, 2026-07-28, took a lot away: the handshake, sessions, and a server’s ability to send requests to the client.
2. A deprecated feature keeps working for at least twelve months, with two shorter exceptions, and even then it only becomes eligible for removal.
3. The extensions differ in status. MCP Apps and Enterprise-Managed Authorization are stable, Tasks is official, Skills is final with implementations still rolling out, OAuth Client Credentials is a draft, and Interceptors and Variants are experimental proposals.
4. A vendor convention works in one host and nowhere else, so it can only ever be an enhancement.
5. My advice: a server built on official extensions is a reasonable bet, an experimental one is a bet on a working group, and the core must work with no extension at all.

Five revisions, named by date

MCP versions carry their release date, not a number. Each revision has its own changelog, and the specification’s home page points at the latest one.

The 2026-07-28 revision is the one that matters for a purchase today, because it changed how a server is built. MCP used to be a stateful protocol: a client opened a session with a handshake, and the two sides could send requests to each other for as long as it lasted. That model fits a process on a laptop and fits a horizontally scaled cloud service badly. The new revision removed the handshake, the session and server-initiated requests. A server that needs input now answers with a request for it, and the client retries; any instance can serve any request.

That split creates two protocol eras, and hosts are crossing between them at different speeds. As of October 2026, Claude Code is the only one of the seven hosts I compared that is confirmed to use 2026-07-28. So the question for a vendor isn’t “which revision?” but “which revisions?”: a server that serves only the new era looks broken in a host that hasn’t caught up, and one that serves only the old era can’t take the new era’s features. The clean approach is to decide the era per request, and several software development kits (SDKs) do that out of the box.

What is deprecated, and what is already gone

The 2026-07-28 revision adopted a formal feature lifecycle, through a Specification Enhancement Proposal (SEP-2596), with a registry of deprecated features. When a SEP marks a feature deprecated, it stays fully functional, but new implementations should not adopt it. It stays for at least twelve months, or at least 90 days when it presents an active security risk, and when that window closes the feature only becomes eligible for removal. Taking it out is a decision for the core maintainers.

Here is what is deprecated today, with its replacement and the earliest it may go. One feature gets less than twelve months: the original HTTP transport, HTTP with Server-Sent Events (SSE), known as HTTP+SSE.

And here is what 2026-07-28 removed outright, which a server built on an older SDK may still depend on: the initialize handshake and its notification, the Mcp-Session-Id header, ping and logging/setLevel, the HTTP GET endpoint, the old resource subscription methods, stream resumability, server-initiated requests, and the experimental tasks of the core, which moved into the redesigned Tasks extension.

What I’d take from this as a buyer: ask for the list of deprecated features a server still uses, with the date each may be removed, and ask whether the server has adopted any since the deprecation, because the policy says it shouldn’t have. My advice to builders is to drop the older era only when their traffic says they can, not when the specification does, and I’d hold a vendor to the same: the question is whether your hosts have moved, not whether the clock has.

The extensions and where each one stands

Several things a server can do in 2026 aren’t in the core protocol at all. They’re extensions: optional additions, always disabled by default, that a client and a server have to agree on for each request. An official extension carries the io.modelcontextprotocol prefix and lives in a repository whose name starts with ext-; an experimental one starts with experimental-ext-.

Two readings of that table help with a roadmap. First, Tasks shows where some extensions end up: it began as an experimental core feature, was redesigned as an extension so it could evolve on real-world feedback, and is meant to move back into the core. Second, an official extension needs a SEP written in the specification’s own MUST and SHOULD language and at least one reference implementation in an official SDK, while an experimental one only needs a working group behind it, and the core maintainers can archive or remove it.

The last row of the diagram is different in kind. Hosts also define conventions of their own, keys in a request’s metadata that one host honours and every other host silently ignores. Claude Code, for example, has keys that keep a tool loaded at session start or force a permission prompt on every call. They’re safe to add and never safe to require.

Reading a vendor’s roadmap

A server’s features sit in three layers, and a roadmap is easier to judge once you place each claim in one:

My advice, by layer:

• The core must work on its own. Tools with text output that stands by itself; resources and prompts as accelerators, not dependencies; every interactive feature with a text fallback; every question to the user with a path that works when no user can answer. If the vendor can’t demonstrate the server in a text-only host, the extensions are decoration on something unfinished.
• Official extensions are a reasonable bet. MCP Apps, Tasks and Skills are negotiated per request and fall back to core behaviour when the host lacks them, so they add value where a host supports them and cost nothing where it doesn’t. Ask the vendor which hosts negotiate each one in its own telemetry, not in the documentation.
• Experimental extensions are a bet on a working group. Interceptors would change how companies deploy MCP, with a standard policy layer for validation, redaction and audit, and I’m watching it. But a roadmap item that depends on it should sit behind a feature flag, and nothing you need should depend on it.
• Vendor conventions are enhancements. If a feature only works in one host because of such a key, the vendor should say so.

Method and caveats

• Built from my guide to MCP servers, written against the 2026-07-28 specification and its registry of deprecated features, and reframed for the people who plan around a server. The statuses and the support facts are as of October 2026, most of them as read on 8 October.
• The timeline, the lifecycle and the layers come from the specification and its extensions’ documentation. The three readings of the roadmap, and the advice by layer, are mine.
• Everything here is framed from the specification. It describes no particular vendor, product or deployment, and client support changes monthly, so check a host’s current documentation before you depend on a feature.