MCP in 2026: stateless, standardised, and what got deprecated

Why a spec revision is your problem

Most of the time it isn't. You install a server, your harness lists its tools, work happens — the protocol underneath is somebody else's concern.

It stops being somebody else's concern in three situations, and they're the reason this page exists:

• If you wrote a server. The 2026-07-28 revision removed the handshake your server is built around, and newly deprecated four features with removal dates attached: Roots, Sampling, Logging and Dynamic Client Registration.

• If you're choosing between servers or gateways. When people say something "supports MCP" they now mean one of at least three different things, and the difference shows up in what you can actually deploy.

• If you hit an error mentioning a protocol version. Then you want a table, not an article.

The short version: MCP is now a stateless request/response protocol, governance moved to a foundation in December 2025, and there's finally a written policy saying how long a deprecated feature survives. Nothing broke on 28 July. Some of it now has an expiry date.

The stateless core

The headline change is that MCP went from a stateful two-way protocol to a request/response one, by deleting everything that made a connection mean something.

One method arrives with all this, and servers MUST implement it: server/discover, which reports the protocol versions and capabilities a server supports along with its identity. A client can call it up front to pick a version, or use it to probe compatibility over stdio.

This is what a request looks like once the handshake is gone. The _meta key names are the normative part:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_invoices",
    "arguments": { "query": "overdue" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": { "name": "your-client", "version": "1.0.0" }
    }
  }
}

With nothing to pin a client to, an MCP server behaves like any other HTTP workload: round-robin load balancing, no sticky sessions, no shared session store. The mandatory Mcp-Method and Mcp-Name headers on Streamable HTTP POSTs address the same thing from the other side — a gateway can route and authorise on headers without parsing the JSON-RPC body.

The pattern that replaced server-initiated calls

A stateless design leaves no channel for a request that starts at the server and targets the client, which is what sat behind roots/list, sampling/createMessage and elicitation/create. All three involved interrupting a client mid-flight.

Multi Round-Trip Requests is the answer, and it works like a retry rather than an interrupt. The server returns a result with resultType: "input_required" and what it needs in inputRequests; the client re-sends the original request with inputResponses filled in.

That's also why every result now carries a required resultType — "complete" for an ordinary one, "input_required" for the interim kind. If a server on an older protocol omits the field, clients MUST treat the result as "complete", and that's what keeps old servers working.

If you ever wrote a server that asks the client to sample from its model, this is your paragraph: the mechanism is deprecated, and the pattern replacing it has no sampling equivalent. The documented migration is to call an LLM provider's API directly.

What a 2026 server now has to do

Past the removals, the revision added obligations that are easy to miss because none of them announce themselves:

• ttlMs and cacheScope are mandatory in results from tools/list, prompts/list, resources/list, resources/read and resources/templates/list, via a new CacheableResult interface. ttlMs is a freshness hint in milliseconds; cacheScope is "public" or "private" and says whether a shared intermediary may cache the response.

• tools/list should return a deterministic order. The stated reason is client-side caching and prompt-cache hit rates — a cost line, not tidiness.

• The error code range got split. -32000 to -32019 stays implementation-defined and existing SDK usage is grandfathered; -32020 to -32099 is reserved for the specification. Three codes moved with it: HeaderMismatch from -32001 to -32020, MissingRequiredClientCapability from -32003 to -32021, UnsupportedProtocolVersion from -32004 to -32022. Separately, resource-not-found went from -32002 to -32602, to line up with JSON-RPC's own Invalid Params.

• Schema constraints got more permissive. inputSchema and outputSchema accept any JSON Schema 2020-12 keyword, and structuredContent accepts any JSON value.

• Authorization got tighter. Authorization servers should send iss per RFC 9207, and clients MUST validate a present iss against their record of the issuer before redeeming the code. Client credentials are bound to the authorization server that issued them: key them by issuer, don't reuse them elsewhere, re-register when the authorization server changes.

• _meta is now documented for trace context. OpenTelemetry propagation for traceparent, tracestate and baggage — the standard way to carry context through a gateway into a server.

What is deprecated, and when it can actually go

Bookmark this part, because "deprecated" used to be a label with no defined outcome and now it has one. The specification's own registry is the source of truth:

Two things in that table are easy to read past.

Roots, Sampling and Logging are the interesting rows. They're not obscure corners — they're what people mean when they talk about the client-side capabilities that make MCP more than a tool schema. All three keep working throughout the deprecation window. If you're writing new code, just don't reach for them.

HTTP+SSE is on the shortest window. Deprecated since the 2025-03-26 revision, reclassified under the formal policy in 2026-07-28, and eligible for removal three months after SEP-2596 reaches Final rather than the twelve months everything else gets. So if you're configuring a remote server today and the transport list offers SSE, that's the legacy path, not the modern one.

Nothing has actually been removed yet. The registry's "Removed" section is empty.

The rule that makes those dates mean something

The 2026-07-28 revision adopted a feature lifecycle policy, which is where every earliest-removal date above comes from. A feature sits in exactly one of three states:

• Active — part of the current revision. Implement it.

• Deprecated — still in the specification, removal scheduled, migration documented. New adopters should avoid it; existing ones should migrate before the earliest removal date.

• Removed — dropped from the draft and absent from the next current revision, but still documented in the last final revision that contained it.

A deprecated feature can't be removed sooner than twelve months after the release of the revision that marked it Deprecated — counted from that release, not from the date the proposal reached Final. Eligibility isn't removal, either: the actual deletion is a maintainer decision taken during release preparation, and a feature can sit Deprecated far longer than the minimum.

There's one escape hatch. The twelve-month floor can be shortened for a feature with an active security risk — a published advisory, or documented exploitation with no in-place mitigation — and even then ninety days is as low as it goes.

The policy binds the SDKs too. Tier 1 SDKs must mark a deprecated surface with their language's native mechanism in their next release, and should warn at runtime when it's exercised; an SDK that consistently doesn't is subject to a tier relegation process. Which means your first warning about a deprecation should arrive in your build output rather than from a page like this one.

Who owns MCP now

On 9 December 2025 MCP became a founding project of the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. The other two inaugural projects were Block's goose and OpenAI's AGENTS.md.

This is the "standardised" half of the picture, and it's the part that should change how you plan. A protocol owned by one vendor can turn on that vendor's product decision. A protocol with a written deprecation policy, a public SEP process and a registry of what's on its way out is one you can build a two-year roadmap against — which is exactly what the twelve-month window is for.

The announcement cited over 97 million monthly SDK downloads and 10,000 active servers. Those are vendor-supplied figures, so treat them as such; the direction is real.

Does any of this break what you run today?

No, and the compatibility story is better than the size of the changelog suggests.

• Servers answer both. A v2 server handles server/discover and the old initialize handshake, so an older client keeps working unchanged.

• Clients fall back. A new client that reaches a server on 2025-11-25 or earlier drops back to the initialize handshake.

• Stateless is opt-in. The TypeScript and Go SDKs need explicit configuration for it; Python v2 servers answer both protocol revisions from a single endpoint.

Beta SDK support landed as Python mcp v2.0.0b1, TypeScript v2, Go v1.7.0-pre.1 and C# v2.0.0-preview.1, with Rust also named in the release announcement.

So if you're asking when you have to rewrite, that's not really the shape of it. The question is narrower: do you use Roots, Sampling or Logging, and is your remote transport SSE? Those answers tell you whether you have work in the next twelve months.

Where the harnesses actually are

This is the part that ages fastest, so we checked it on the wire instead of in a docs page. We connected three CLIs to a stdio server that writes down everything it receives, on 3 August 2026:

Claude Code 2.1.193             initialize   protocolVersion 2025-11-25
Cursor CLI 2026.07.23-e383d2b   initialize   protocolVersion 2025-11-25
Codex CLI 0.146.0               initialize   protocolVersion 2025-06-18

Every one of them opened with the handshake the 2026-07-28 revision deletes, and none asked for 2026-07-28. That's not a fault — the SDKs implementing the revision are still in beta, and the compatibility rules above exist precisely so clients can migrate gradually. It does mean something practical though: a server you write today still has to understand initialize, because that's what every client we could observe sent it.

Read it off the wire yourself

Everything in the section above came out of one small JavaScript file. The version numbers in this lesson will age faster than the shape of the answer will, so the durable move is to re-run the check rather than trust the table.

Save the artifact below, register it in your harness as a stdio server, and trigger anything that makes the harness connect — a health check, a tool listing, a one-line prompt. The log file gets the raw JSON-RPC in both directions.

mkdir -p /tmp/mcp-probe && cd /tmp/mcp-probe
# save mcp-probe.js here, then add it as a stdio server in your harness
tail -f /tmp/mcp-probe/probe.log

Three things worth looking for.

The opening message. initialize means your client is on the old protocol. A first request carrying io.modelcontextprotocol/protocolVersion in _meta, or a call to server/discover, means it has moved.

The protocolVersion value. It tells you which revision's rules your client is playing by, which is the fact you want when a server misbehaves.

Whether it reconnects. Some CLIs start a fresh server process per invocation, which shows up as a repeated handshake in the log and matters if your server is expensive to start.

Run it in a scratch directory rather than a repository you care about, and take the server out of your configuration afterwards.

The one-screen version

• The current revision is 2026-07-28. The one before it was 2025-11-25.

• MCP is stateless: no handshake, no session header, no ping. Version and capabilities travel in _meta on every request.

• Server-initiated requests are gone. The replacement is Multi Round-Trip Requests — the server returns resultType: "input_required" and the client retries with inputResponses.

• Deprecated with a date: Roots, Sampling, Logging and Dynamic Client Registration, none of them removable before 2027-07-28. HTTP+SSE is on a shorter window than any of them.

• The deprecation floor is twelve months, or ninety days where there's an active security risk.

• Governance sits with the Agentic AI Foundation under the Linux Foundation, since 9 December 2025.

• Nothing breaks today. New servers answer the old handshake, new clients fall back to it, and stateless mode is opt-in.

• No harness we probed speaks 2026-07-28 yet. Check yours instead of assuming.