Removing a Redis dependency did more for adoption than any feature
GitHub removed the Redis databases used for MCP sessions in July, making servers deployable on ordinary HTTP infrastructure. The unglamorous change is the one that moves numbers.
The 2026-07-28 MCP specification removed the initialize/initialized handshake and the Mcp-Session-Id header entirely, making the protocol core stateless. GitHub's MCP server adopted the new specification on 23 July, dropping the Redis databases it used for session state. Database writes on initialize are gone and database reads are gone from every call.
Requiring a stateful backing store is one of the most effective ways to stop people deploying something. Running a remote MCP server previously meant a shared Redis for session state, or a gateway doing packet inspection to route each request back to the one box holding the connection. Both are operational commitments with an owner and an on-call rotation.
Removing it means an MCP server deploys the way every other web service in the last decade deploys — horizontally, statelessly, on infrastructure a team already runs. That is not a feature; it is the removal of an excuse.
Sessions were there for a reason, and the interesting question is what was given up. Statelessness usually costs something — the client carries more per request, or capabilities that depended on server-side continuity get reworked. It has prompted a fair question in the commentary: if MCP is stateless HTTP with a schema, how much of it is now just an API? The honest answer is that the schema and the tool-discovery convention were always the valuable part.
It is a useful reminder in a month full of capability announcements: adoption is usually limited by operational friction, not by what a system can do. The download curve is what removing friction looks like.
GitHub Changelog — GitHub MCP Server supports the next MCP specification → · Model Context Protocol — The 2026-07-28 Specification →