MCP overhauls core design to eliminate session management burden on server operators

The Model Context Protocol (MCP) is preparing its most significant overhaul yet. Maintainers froze the release candidate in May, with the final specification arriving July 28. While the changelog lists major removals—sessions, initialization handshakes, and three core features deprecated—the intent is more surgical: simplifying the protocol by returning common problems to the infrastructure layers already equipped to handle them. The practical effect addresses a persistent operational friction: teams deploying remote MCP servers no longer need to build custom machinery to handle protocol-level state.

The original design vs. real-world deployment#

MCP initially assumed connections between a desktop application and a local process using standard input and output, where setup negotiations were cheap to perform over durable links. This design worked well at small scale but created friction as servers moved to cloud deployments with multiple instances.

The trouble centered on two mechanisms. First, servers created an Mcp-Session-Id that locked clients to a single instance. Scaling horizontally then required session affinity, externally shared session stores, or intelligent gateways that parsed JSON to route calls correctly—distributed-systems infrastructure that had nothing to do with the actual service logic. Second, capability negotiation happened once at connection time, producing a list that could vary between connections and made caching unreliable. Application developers ended up solving problems the protocol itself had introduced.

Statelessness as the redesign principle#

Six enhancement proposals target one goal: making each request self-contained. Protocol version and client capabilities now travel in _meta fields on every call. Servers expose their own capabilities through a new server/discover method that clients can invoke independently, either upfront or on demand. This embodies what the maintainers call "pay-as-you-go complexity"—the protocol stays minimal, and state handling emerges only where features actually require it.

When servers do need to track application state, they adopt an explicit handle pattern familiar from HTTP shopping carts: a tool returns an identifier like basket_id, which the model passes back as a parameter in the next request. Database identifiers, resource URIs, and task handles work this way. The advantage over hidden transport-layer session metadata is that handles appear in prompts and logs, making them visible to models and audit trails. The cost is binding them to authenticated users and validating permissions on each use, rather than trusting them as proof of authorization.