GitHub MCP Server Adds Early Support for Stateless MCP, Removing the Connection Phase and Shared Session Storage

GitHub announced on July 23 that the official GitHub MCP Server had added early support for the MCP `2026-07-28` specification. The core of this update is not the addition of new tools, but a rewrite of the transport model for remote agent tools: the `initialize`/`initialized` handshake and `Mcp-Session-Id` have been removed, while the protocol version, client information, and capabilities are now included with every request. As a result, consecutive calls from the same agent can be routed to different instances by a standard round-robin load balancer, eliminating the need for sticky sessions or a shared session store such as Redis.

To let gateways route, rate-limit, and scan traffic without parsing the JSON-RPC payload, the new specification requires Streamable HTTP requests to include headers such as `Mcp-Method` and `Mcp-Name`. List and resource-read results can also specify cache lifetimes through `ttlMs` and `cacheScope`. GitHub said this allowed its service to eliminate database writes during initialization and session reads on every call, while also removing the need for deep packet inspection for logging and secret scanning. Login or elicitation flows that previously required multiple rounds of interaction now have the server return an `InputRequiredResult`; after collecting the required input, the client resubmits the original request.

This has direct operational value for engineering teams running self-hosted MCP services, but “stateless” applies only to the protocol layer. Browser, shopping cart, or workflow state must still be passed explicitly as a handle in tool parameters. The new version also moves Tasks to an extension, changes the error code used when a resource does not exist, and deprecates core capabilities including Roots, Sampling, and Logging. Although Tier 1 SDKs retain backward compatibility, implementations that use hand-written protocol code, depend on the legacy Tasks API, or match fixed error codes should still run the official conformance suite. The upgrade should not be treated as a simple protocol version-string change.