AI
MCP Protocol Ditches Sessions, Leaving Developers to Ask If It's Just REST Now
The Model Context Protocol's shift to stateless design eliminates session management but also sparks debate about whether the move reveals MCP was always destined to be a conventional API.
InfoQ
Anthropic's Model Context Protocol has undergone a fundamental redesign in its July 2026 specification, scrapping the stateful session model that previously required agents to maintain persistent connections to servers. The shift promises cleaner infrastructure and easier scaling—but it's sparked a sharp community debate about whether the protocol just became a more elaborate version of a standard REST API.
The Core Change: Sessions Are Gone#
The protocol previously relied on session handshakes that created a persistent connection between client and server, tracked via an Mcp-Session-Id header. Each request had to find and maintain the state tied to that session, forcing load balancers to pin clients to specific instances and making auto-scaling cumbersome. The new design eliminates this altogether: every request is now stateless and can land on any server instance, carrying only the protocol version, client identity, and capabilities it needs.
What Statelessness Gains (and What It Cost)#
Removing sessions solves real infrastructure problems. Servers no longer need to preserve client state, deployments can scale without managing session migration, and load balancing becomes practical. However, the protocol compensates by adding two mandatory HTTP headers: Mcp-Method and Mcp-Name. These headers expose routing information that previously lived only inside the JSON-RPC payload, allowing gateways and rate limiters to inspect tool calls without parsing the message body—much like they do with ordinary REST APIs. Some implementations also copy tool arguments into headers for granular routing.
Server-initiated requests also changed. Where agents once kept a stream open for human approval, they now receive an input_required response, collect the answer as a separate request, and retry—simpler to deploy but no longer a single, held invocation.
The Philosophical Divide: Did MCP Reinvent the Wheel?#
The Hacker News discussion revealed two camps with competing takes. One side argues the move vindicates a long-standing principle: stateless design was always the right answer, and MCP should never have been stateful in the first place. As one commenter put it, the protocol is now "just another REST API endpoint" that works with existing infrastructure. Another noted the similarity to lessons learned from Sun RPC decades ago—stateless is universally preferable, stateful only when unavoidable.

