Blog
2 min read

MCP's 2026-07-28 Specification: A Stateless Protocol and What Breaks

The Model Context Protocol released its 2026-07-28 specification, the first since November 2025. The core becomes stateless request/response — no initialize handshake, no Mcp-Session-Id — with routing headers, multi round-trip requests, cacheable lists, auth hardening and deprecated Roots, Sampling, Logging and HTTP+SSE. What changes for server builders and users.

The Model Context Protocol shipped its 2026-07-28 specification — the first new revision since November 2025, and the biggest change since MCP launched. Claude Code switched to negotiating it by default for local stdio servers in early October. (What Is MCP?)

The headline: stateless

MCP moves from a bidirectional, stateful protocol to request/response:

  • The initialize / initialized handshake and the Mcp-Session-Id header are retired.
  • Every request carries its protocol version, client identity and capabilities in _meta.
  • An optional server/discover call lets clients learn capabilities up front.

The practical effect: any server instance behind a plain round-robin load balancer can serve any request. Hosting a remote MCP server becomes ordinary web-service work — no sticky sessions. (What Is a Load Balancer?)

Other changes

  • Routing headers: Streamable HTTP requests must include Mcp-Method and Mcp-Name, so gateways and rate limiters can route and limit without parsing JSON. (MCP Transports: stdio vs Streamable HTTP)
  • Multi round-trip requests replace server-initiated elicitation/create, sampling/createMessage and roots/list: the server returns resultType: "input_required", and the client retries with the answers.
  • Cacheable lists: tools/list, prompts/list, resources/list and resources/read return ttlMs and cacheScope, in a deterministic order.
  • Authorization hardening: issuer validation (RFC 9207), application_type for desktop/CLI redirects, credentials bound to their issuer, and Client ID Metadata Documents preferred over Dynamic Client Registration (now deprecated).
  • Extensions framework: Tasks, MCP Apps and Enterprise Managed Authorization become formal extensions.

Deprecated

  • Roots, Sampling and Logging — keep working for at least twelve months; don't adopt them in new code.
  • The legacy HTTP+SSE transport — a year-long off-ramp. Use Streamable HTTP.

What to do

If you build MCP servers:

  1. Upgrade to an SDK that supports 2026-07-28 — TypeScript, Python, Go and C# do; Rust is in beta.
  2. Remove any reliance on session IDs. If a tool needs state across calls, mint an explicit handle (an ID) from one tool and have the model pass it back as an argument.
  3. Replace server-initiated requests with multi round-trip responses.
  4. Move off HTTP+SSE.

If you only use MCP servers: update your client (claude update). If an older stdio server stops working in Claude Code, MCP_PROTOCOL_NEGOTIATION=legacy restores the old negotiation while its maintainer catches up. (Connecting MCP Servers to Claude Code)

Source: MCP blog: The 2026-07-28 Specification · Claude Code changelog

EasySpawn gives you a persistent server with HTTPS where a remote MCP server can run next to your app and database — and Claude Code to migrate it to the new spec. See how it works or join the waitlist.

Related: How to Build an MCP Server · Secure MCP Servers · Best MCP Servers · MCP vs API

Keep reading