Skip to main content
← All news
news

MCP’s July 2026 Spec Drop: Stateless Core, MRTR, and Why “MCP 2.0” Is Half Right

By AgentRiot Editorial

The protocol revision is dated 2026-07-28. The “2.0” label mostly belongs to the Python and TypeScript SDKs that shipped with it.

MCP specification 2026-07-28 release slate
mcpmodel-context-protocolagentsprotocolssdkinfrastructure

On July 28, 2026, the Model Context Protocol project published specification revision 2026-07-28 and flipped Tier 1 SDKs to match. The headline change is not a feature checkbox. MCP’s core is no longer a bidirectional, session-bearing conversation. It is a request/response protocol that can sit behind ordinary round-robin load balancers without sticky sessions or shared session stores.

If you run agent tooling for a living, this is the MCP story that matters more than another model launch. Tool servers stop looking like special snowflake long-lived sockets and start looking like the rest of the web.

Name the thing correctly

People on X are already calling this “MCP 2.0.” That shorthand is useful in a feed and imprecise in a migration plan.

  • The protocol revision is named 2026-07-28. That is the string clients and servers negotiate.
  • The previous stable revision was 2025-11-25.
  • Python SDK v2.0.0 and the split TypeScript v2 packages (@modelcontextprotocol/server, @modelcontextprotocol/client, and friends) are separate major version lines that implement the new revision. Moving to SDK v2 is not the same switch as speaking 2026-07-28 on the wire, and the project has been explicit that those upgrades can be staged.

So: “MCP 2.0” is a fair informal label for the whole package. For docs, gateways, and compatibility matrices, use the date-stamped protocol version.

What actually changed in the core

Sessions and the initialize handshake are gone

The new core retires:

  • the initialize / initialized exchange
  • the Mcp-Session-Id header
  • the assumption that list endpoints vary per connection

Every request is supposed to carry what it needs. Protocol version and client capabilities ride in _meta. Optional client identity does too. Servers that still need multi-call state are told to mint an explicit handle from a tool and have the model pass it back as an ordinary argument - state the model can see, not session glue hidden in the transport.

If a client wants capabilities up front, there is a new required server RPC: server/discover. It is not a mandatory first step for every call path, but servers must implement it.

Multi Round-Trip Requests replace held-open server-to-client asks

Sampling, elicitation, and roots used to lean on server-initiated requests over a live bidirectional stream. That fights a stateless deployment model.

Multi Round-Trip Requests (MRTR) flip the pattern:

  1. Client calls a tool.
  2. Server may return resultType: "input_required" plus the extra requests it needs answered.
  3. Client retries the original call with inputResponses.

Ordinary completed results now carry resultType: "complete". Clients must treat missing resultType from older servers as complete.

This is the piece that lets a serverless MCP tool pause for confirmation - “this query deletes data,” “this project will cost X” - without parking a sticky websocket on one machine.

Headers become first-class routing surface

Streamable HTTP POSTs must include:

  • Mcp-Method
  • Mcp-Name when a named tool, resource, or prompt is involved

Gateways, WAFs, and rate limiters can route and meter without parsing JSON bodies. That is unglamorous and exactly what production agent platforms need.

List results become cacheable on purpose

tools/list, prompts/list, resources/list, resources/read, and related list surfaces now carry cache hints:

  • ttlMs
  • cacheScope (public or private)

Servers should also return tools in a deterministic order. The point is not aesthetics. Stable catalogs help client-side caching and keep upstream LLM prompt caches from thrashing every reconnect.

Subscriptions and tasks get reshaped

  • The old HTTP GET notification path and resource subscribe/unsubscribe flow give way to subscriptions/listen: one long-lived POST response stream clients opt into by notification type.
  • Experimental tasks leave the core and move into the official extension io.modelcontextprotocol/tasks, with poll-based tasks/get and client-to-server tasks/update. Long-running work is an extension, not a hidden core assumption.

Authorization keeps getting stricter

The revision continues the multi-year cleanup of OAuth edges that burn implementer time:

  • authorization responses should include iss per RFC 9207; clients must validate it before redeeming a code
  • clients set application_type during Dynamic Client Registration so desktop/CLI localhost redirects stop getting treated like web apps
  • client credentials are bound to the issuer that minted them
  • Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents (CIMD), with DCR kept for compatibility for now

Deprecations with a real clock

Roots, Sampling, and Logging are deprecated. HTTP+SSE transport is classified as Deprecated under the lifecycle policy. The project’s deprecation policy sets a minimum twelve-month window, so this is not a surprise kill switch on day one - but new implementations should not adopt the deprecated paths.

Also gone from Streamable HTTP: SSE stream resumability / Last-Event-ID redelivery. A broken response stream means re-issue the request with a new ID.

Ecosystem claims worth quoting carefully

The official blog’s adoption numbers are project-reported, not third-party audited:

  • Tier 1 SDKs: “close to half-a-billion downloads a month”
  • TypeScript and Python SDKs: each “crossing the 1 billion total downloads threshold”

Treat those as maintainer metrics. The more operationally interesting signals in the same post are the day-zero infrastructure quotes: Amazon Bedrock AgentCore framing around the stateless core and Tasks; Cloudflare Agents SDK support claims; enterprise vendors lining up around scale and auth. Those are attributed endorsements, not independent benchmarks.

Why AgentRiot readers should care

MCP stopped being “how Claude talks to a few tools” a while ago. It is becoming the default tool bus for agent hosts, IDEs, gateways, and internal enterprise catalogs. A protocol that required sticky sessions was always going to hit a wall the moment teams tried to run thousands of MCP servers the way they run ordinary APIs.

2026-07-28 is the release that admits that wall exists and redesigns around it:

  • scale like HTTP
  • keep interactive mid-tool flows via MRTR
  • push long-running work into an explicit Tasks extension
  • give gateways headers they can actually use
  • put a deprecation policy on the calendar instead of informal “maybe later”

If you maintain an MCP server today, the practical question is not “is this cool?” It is “where did I hide session state, and how do I surface it as handles the model can pass?”

Migration reality, not launch theater

Stable SDKs for the revision are already tagged:

  • Python SDK: v2.0.0 (2026-07-28)
  • TypeScript SDK: split @modelcontextprotocol/*@2.0.0 packages (around 2026-07-27/28)
  • Go and C# Tier 1 lines are updated for the revision as well; Rust is called out as beta support on the blog

Compatibility is intended to be staged, not cliff-edged. Older protocol traffic does not vanish on the publication date. Clients speaking the new revision are expected to fall back to initialize against older servers. Server authors still need to budget real work if they depended on session IDs, server-initiated stream requests, SSE resume, or deprecated roots/sampling/logging.

The migration pain is the story. The project is choosing breaking protocol cleanup over papering over production gaps. That is the right kind of boring for infrastructure.

Bottom line

Call it MCP 2.0 in conversation if you want. Ship and document it as protocol 2026-07-28, with SDK v2 as the implementation lane many teams will actually bump.

The substance is simple: MCP is growing up into production agent infrastructure - stateless by default, interactive when needed, extensible for long jobs, and stricter about auth and deprecation clocks.

Sources