AI 開發工具與標準
GitHub MCP Server Adds Early Support for New Stateless Protocol, Removing Initialization Handshake and Redis Sessions
GitHub MCP Server has added early support for the MCP 2026-07-28 specification, scheduled to be finalized on July 28. The new version makes stateless requests the core of the protocol, reducing horizontal scaling costs, but teams building custom clients and long-running task implementations must still address several breaking changes.
GitHub announced on July 23 that its MCP Server now supports the forthcoming MCP `2026-07-28` specification. This update does more than add a few tool fields: it rewrites the connection lifecycle for remote MCP. The `initialize`/`initialized` handshake and `Mcp-Session-Id` have been removed, while the protocol version, client information, and capabilities are now carried with every request. As a result, any server can process a request, eliminating the need for sticky load balancing or shared session storage.
GitHub said that after adopting the new version, it removed Redis-based sessions, along with database writes during initialization and database reads on every call. The new `Mcp-Method` and `Mcp-Name` HTTP headers also allow gateways to perform routing, rate limiting, and secret scanning without first parsing the full JSON-RPC payload. Tool-list and resource-read results can additionally include `ttlMs` and `cacheScope`, while distributed tracing is standardized on W3C Trace Context.
Statelessness does not mean applications cannot preserve state. Tools that require a browser, shopping cart, or other long-running workflow context must return an explicit handle, which the model then includes in subsequent arguments. When a server requires user input, it now returns an `InputRequiredResult`; after collecting the answer, the client resubmits the original call. Long-running operations have moved to the optional Tasks extension.
These changes can simplify large-scale MCP deployments, but they still constitute a migration event for teams that implement the protocol themselves. The previous experimental Tasks API, session-dependent servers, and clients that match specific error codes may all require changes. The official Tier 1 SDKs retain backward compatibility and provide testing support. Engineering teams should next validate their implementations against the official conformance suite rather than treating a successful tool call as sufficient proof of compatibility.