AI 標準與代理基礎設施
MCP 2026-07-28 Removes Connection-Phase Sessions as Tool Servers Move to Stateless HTTP
The new MCP revision removes the initialization handshake and `Mcp-Session-Id`, allowing any server instance to handle an individual request. This is a breaking protocol change; deployers should retain version negotiation and fallback to the previous version until the final release and major SDKs are fully aligned.

The new version of the Model Context Protocol (MCP), scheduled to be finalized on July 28, rewrites the connection lifecycle between agents and tool servers. Under the previous Streamable HTTP specification, clients typically ran `initialize` first and then used `Mcp-Session-Id` to maintain subsequent calls. The new version removes both, requiring every request to carry the protocol version, client capabilities, and identity information. It also adds `server/discover`, allowing clients to query the versions and capabilities supported by a server. In practice, requests are no longer pinned to a specific instance, so remote MCP services can sit directly behind a standard round-robin load balancer, reducing the need for shared session stores and sticky routing.
State does not disappear entirely; instead, it moves up to the application layer. Tools that need to preserve a shopping cart, browser, or workflow state across calls must return an explicit handle, which the model then sends back in the next call. When a server needs confirmation or additional input from the client, it now uses Multi Round-Trip Requests: the server first returns `input_required`, and the client resubmits the original request after obtaining user input. Long-running work moves to a separate Tasks extension and is managed through `tasks/get`, `tasks/update`, and `tasks/cancel`.
The new version also requires HTTP POST requests to include `Mcp-Method` and `Mcp-Name`, enabling gateways to route and rate-limit traffic without parsing the JSON body. Tool and resource lists gain `ttlMs` and `cacheScope`, while OpenTelemetry trace context is standardized. OAuth changes add requirements such as issuer validation and isolating credentials by authorization server.
The migration risks should not be underestimated: `ping`, legacy logging operations, and several notifications have been removed, while Roots, Sampling, and Logging are entering deprecation. Requests can also no longer be resumed after a disconnection using an SSE event ID. At the time of data collection, the official changelog remained under a draft path, so engineering teams should verify the final schema, adoption status of their SDKs, and downgrade behavior. Replacing only the version string and deploying directly to production is not advisable.