MCP Went Stateless—But Your Application Still Has State

The 2026-07-28 Model Context Protocol revision makes remote MCP servers stateless at the protocol layer, but applications still require state management. A practical migration guide emphasizes separating protocol state from domain state, deleting unnecessary state, and making remaining state explicit, authorized, observable, and resilient.

Member-only story MCP Went Stateless. Your Application Didn’t. A practical migration guide for moving remote Model Context Protocol servers away from protocol sessions without losing the application state your tools actually need. The 2026–07–28 Model Context Protocol revision changes a foundational assumption for remote MCP deployments: an individual protocol request can be handled without relying on an earlier initialization handshake or an MCP session identifier. That is a major improvement for horizontally scaled services. It does not, however, make shopping baskets, browser contexts, database workflows, or long-running jobs disappear. MCP can become stateless at the protocol layer while the application behind it remains stateful. This distinction matters because backward compatibility can hide unfinished migration work. An older server may continue to function through legacy negotiation while retaining sticky routing, shared session storage, connection-aware deployments, and implicit state that no one has formally classified. The goal of migration is therefore not merely to accept a new protocol version. It is to separate protocol state from domain state, delete state that is no longer necessary, and make the remaining state explicit, authorized, observable, and resilient.