Four days before the 28 July 2026 cutover to a stateless MCP core, GitHub says its MCP Server has been updated to track the new specification, per the GitHub Changelog dated 23 July. The headline for anyone wiring a coding agent into a pipeline is what the server no longer has to remember between calls: per-session state, and the Redis it used to sit in.
What the stateless core removes
MCP is the protocol coding agents use to reach tools, and until this spec revision the reference shape carried per-session state on the server. Per GitHub, the new version pushes to a stateless core, which the changelog frames as easier to scale.
GitHub's server, which is built on the official Go SDK per the post, ships three concrete implementation changes as part of tracking the new spec. First, Redis-backed sessions are gone: database writes on initialize are removed, and database reads are removed from every call. Second, the server still reads some values out of each request for logging and secret scanning, but it does that without deep packet inspection on the payloads it forwards. Third, the elicitation implementation is upgraded, and the stdio MCP server now uses URL elicitation for user login.
Why an on-call cares
A stateful protocol demands session affinity. In practice that means an MCP endpoint behind more than one replica needs sticky routing or a shared session store, and both are the kind of thing that show up as odd, hard-to-repro tool failures when an agent's session hops backends mid-workflow. Pulling the per-session store out of the hot path removes that class of failure. It also removes a Redis dependency from the server's uptime picture, which is one less thing to page on at 3am.
The trade is where the state lives instead. If the server stops carrying the session, the client and the transport have to carry more of it. That is what the elicitation change signals for the stdio MCP server: login is handed to a URL flow the client walks through, so the server side does not have to remember who is on the other end of the socket. For pipelines that spin up a fresh agent per job, that model actually lines up with how CI already treats state.
Migration, per the changelog
GitHub's guidance to consumers is short. Because the tier 1 SDKs preserved backwards compatibility and shipped beta support ahead of the cutover, clients on a current SDK do not need to change anything to keep working. Read literally, that puts the change at the runtime level, not the wire contract.
The catch to flag for on-call is what "no action required" does not cover. It describes call-site compatibility, not deployment topology. If your own MCP server, or a self-hosted proxy in front of GitHub's, was leaning on the old session lifetime for auth caching or rate limiting, that assumption goes away when the upstream stops storing it. Worth checking before 28 July, not after.
Where other MCP implementations sit
MCP is an open specification, and GitHub is one of several servers CI teams reach for. The various third-party servers that wrap tool APIs each choose where to hold state; some are already stateless at the transport level and some are not. The spec's new stateless core sets the baseline the ecosystem now has to hit. GitHub is early, per its own account. The interesting reads over the next weeks will be the MCP servers that are late, and what breaks when a client on the new spec talks to one that has not caught up.
Top comments (1)
The migration test Iād add is randomized replica routing plus process restarts between
initializeandtools/call. That exposes any proxy, auth cache, limiter, or client that still assumes affinity. Also, stateless transport does not make tool semantics idempotent: retry the same write with an idempotency key and verify one effect, then revoke credentials mid-workflow and confirm the next request fails everywhere. Those two checks catch the hidden state that often survives after Redis is removed.