Skip to content
AI Primer
release

MCP updates remote servers to stateless mode in 2026-07-28 protocol release

The 2026-07-28 MCP update makes remote servers stateless for serverless, edge, and horizontally scaled deployments. It also adds app, task, managed-auth, and auth-hardening extensions.

6 min read
MCP updates remote servers to stateless mode in 2026-07-28 protocol release
MCP updates remote servers to stateless mode in 2026-07-28 protocol release

TL;DR

  • MCP 2026-07-28 is the fifth spec release, and ClaudeDevs' launch post called it the largest protocol update since launch.
  • Remote MCP servers no longer need protocol-level session state; ClaudeDevs' deployment note says they can run on serverless, edge infrastructure, or horizontally behind any load balancer.
  • Extensions graduated into a formal path: ClaudeDevs' extensions post names MCP Apps, Tasks, and Enterprise Managed Auth as first examples.
  • Auth and lifecycle work landed in the same release; ClaudeDevs' auth note points to auth hardening and a formal deprecation policy.
  • Practitioners read the core change as MCP becoming ordinary request/response infrastructure, with rohanpaul_ai's breakdown describing independent requests and marcelpociot's Laravel note calling it easier to build against.

The official MCP post has the operator candy: Mcp-Method and Mcp-Name headers, ttlMs and cacheScope hints, MRTR for elicitation without held-open streams, and explicit state handles when an app still needs cross-call memory. The Claude rollout post adds connector-directory scale: 950+ MCP servers, millions of daily users, dashboards for published connectors, and MCP tunnels for private-network servers. The TypeScript migration guide has the migration gotcha: v2 does not speak 2026-07-28 by default, it requires explicit opt-in.

Stateless core

The release changes the operational unit from a session to a request. According to the official MCP post, each request now carries its protocol version, client identity, and client capabilities in _meta.

The stateless core has six concrete mechanics:

  • initialize and initialized are retired.
  • Mcp-Session-Id is retired from Streamable HTTP.
  • server/discover is optional for clients that want capabilities up front.
  • Any request can land on any instance behind a plain round-robin load balancer.
  • App-level state can still exist through explicit server-minted handles passed as tool arguments.
  • TypeScript, Python, Go, and C# SDKs were updated for the revision, per the MCP release post.

omarsar0 read the shift as making MCP easier to adopt, manage, and deploy across applications omarsar0's reaction. cedric_chee reduced the model to the punchline: MCP becomes HTTP-like request/response cedric_chee's reply.

Headers and cache hints

The stateless design comes with HTTP-visible routing metadata, not just a deleted session header. The 2026-07-28 changelog says Streamable HTTP POST requests now require standard MCP headers.

The operator-facing pieces are compact:

  • Mcp-Method carries the JSON-RPC method.
  • Mcp-Name carries the tool name when applicable.
  • x-mcp-header can expose selected tool parameters as custom headers.
  • tools/list, prompts/list, resources/list, and resources/read now carry ttlMs and cacheScope.
  • Servers should return list results in deterministic order, which the spec changelog ties to client-side caching and LLM prompt-cache hit rates.

Multi Round-Trip Requests

MRTR is the interactive-tool escape hatch for a stateless transport. The MCP release post says it replaces server-initiated elicitation/create, sampling/createMessage, and roots/list flows that previously needed a held-open stream.

A tool can now return resultType: "input_required" with the requested inputs, then the client retries the original call with inputResponses. In the same release post, Supabase said this unlocks confirmations for actions such as project creation costs or queries that would delete data.

Extensions

Extensions are now versioned protocol surface, rather than feature sprawl inside the core.

The release names three first-class examples:

  • MCP Apps: server-rendered UIs in a sandboxed iframe.
  • Tasks: long-running and async operations, moved into the io.modelcontextprotocol/tasks extension with tasks/get and tasks/update, according to the MCP release post.
  • Enterprise Managed Auth: centrally controlled access through an identity provider.

The Apps path already has working demos. _avichawla built a Hugging Face fine-tuning studio inside Claude with Hub search, chat-template formatting, LoRA rank, quantization, batch size, learning-rate controls, AutoTrain execution on HF GPU infrastructure, and post-training chat _avichawla's fine-tuning studio demo.

Authorization and deprecations

The release hardens OAuth behavior while putting old surfaces on a clock.

The official MCP post lists the auth changes as:

  • Authorization servers should return iss per RFC 9207, and clients must validate it before redeeming a code.
  • Clients set application_type during Dynamic Client Registration, which addresses desktop and CLI localhost redirect failures.
  • Client credentials are bound to the issuer that minted them.
  • Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents.

The same post says Roots, Sampling, Logging, and legacy HTTP+SSE transport are deprecated with at least a 12-month runway. zeeg said Sentry's MCP server already supports CIMD zeeg's CIMD note.

SDK opt-in

The sharpest compatibility detail is in the TypeScript migration guide: hand-constructed Client, Server, and McpServer instances keep speaking the 2025-era protocol unless 2026-07-28 is explicitly selected.

The guide describes three negotiation modes:

  • legacy, the default, stays on the 2025 handshake.
  • auto probes server/discover and can fall back after an extra round trip.
  • pin: "2026-07-28" speaks modern only and fails against 2025-era servers.

Microsoft's .NET SDK v2 post adds the C# shape: the 2026-07-28 SDK makes statelessness the default while leaving stateful sessions available as an explicit opt-in.

Claude rollout

Claude is rolling the spec into product surfaces, not just publishing protocol text.

The Claude rollout post lists these Claude-side pieces:

  • More than 950 MCP servers in Claude's connectors directory.
  • Millions of people using connectors every day.
  • MCP Apps rendering interactive UI directly in the conversation.
  • Enterprise-managed auth where admins authorize once and users inherit access through IdP groups.
  • Connector dashboards for adoption, errors, latency, and usage by product surface.
  • MCP tunnels, in research preview, for connecting Claude to private-network MCP servers without public endpoints, inbound firewall rules, or origin IP allowlisting.

CLI versus native MCP

The post-release debate also hit the CLI comparison. zeeg argued that adoption should not be forced through a CLI narrative because their CLI has "like 5%" of MCP usage zeeg on CLI usage.

zeeg's technical split was specific: MCP covers auth, native tool calls, permissions, and agent-native standards, while a CLI depends on colocated docs to work well zeeg on agent-native concerns. Their planned hybrid path is sentry mcp, likely launching stdio through the CLI while also bundling a native MCP connection zeeg's hybrid CLI plan.

Further reading

Discussion across the web

Where this story is being discussed, in original context.

On X· 4 threads
TL;DR1 post
Stateless core2 posts
Authorization and deprecations1 post
CLI versus native MCP4 posts
Share on X