The new MCP specification removes initialization sessions and puts the information needed to handle each request into that request.
2
Multi-roundtrip requests let a server pause for input, finish the current request, and continue later without an open stream, sticky sessions, or shared state.
3
The release adds formal extensions, improves authorization, and gives developers SDK support for updating clients and servers with less manual protocol work.
Summary
Alex Hancock explains the largest MCP protocol change since its launch. MCP started with local hosts and data sources, but more usage now happens between remote clients and servers. The new design removes sessions and initialization, so each request carries the information a server instance needs. This makes horizontal scaling easier because requests can move between instances without session pinning or a shared session store. Multi-roundtrip requests handle flows such as elicitation through separate requests, which avoids keeping a stream open while waiting for user input. The release also formalizes extensions. MCP apps deliver HTML, JavaScript, and CSS interfaces, while tasks model long-running work that clients can poll. Authorization follows more of the relevant OAuth behavior, including issuer validation. Alex recommends using an MCP SDK rather than constructing protocol messages manually, and points to the newly released Rust SDK 3.0.0.
MCP is moving from local connections to remote deployments
Alex frames the release around MCP's change in usage. Early MCP deployments usually had a desktop host and a data source on the same machine, with standard input and output as the transport. Remote usage is now more common, so the protocol has to work when the client and server are separate systems. The new release responds to that shift with changes aimed at deployment patterns that need scaling, load balancing, and independent server instances.
Sessions made horizontally scaled MCP servers difficult to operate
In the previous specification, initialization created a session ID and per-session state. That state included the protocol version, client capabilities, and server capabilities. A load balancer could then send the next request to a different server instance that did not have the session state. Teams worked around this by pinning a client to one instance or by putting session data in a shared store. Both approaches added operational work, especially when deploying new versions or draining a server pool.
Stateless MCP puts request context into every request
The new protocol removes initialization and sessions. Each client request contains the information a server instance needs to handle it completely, including the relevant metadata. Any server instance can therefore handle any request from any client. Alex presents this as the main benefit of statelessness: deployments can use ordinary load balancing and horizontal scaling without sticky session rules or a separate shared session store.
Alex uses elicitation to show how multi-roundtrip requests change protocol behavior. Previously, a server could send a request to the client over an open stream and wait in memory for the response. If the response reached another server instance, the instances needed shared storage and coordination. Under the new pattern, the server returns an incomplete result that asks for input. The client collects the information, then sends another request containing the additional state so the server can continue.
Formal extensions give MCP features a separate place to evolve
The specification now defines a formal extension mechanism. Alex names MCP apps as the first extension, allowing clients to receive a fully rendered HTML, JavaScript, and CSS user interface. He also describes tasks as an extension for long-running work. A tool call creates a task and returns a task ID, while the client polls for its status. A task can remain in progress, request input, and eventually become completed.
Tasks can model work that lasts beyond one request
Tasks extend MCP to work that may involve a person or take hours or days. Alex gives examples such as a database migration, a human approval step, or work that continues while people are away for the weekend. The client uses the task ID to request status, sees whether the task is still working or needs input, and polls again later. This moves long-running behavior into an extension rather than keeping it in the protocol core.
The release updates MCP authorization to follow more closely the relevant OAuth specifications. The practical change Alex calls out is that authorization servers need to return the issuer parameter, and clients need to validate it before redeeming a code. Clients do not yet reject authorization responses that omit the issuer, but Alex says they will in a future MCP version. Developers should check client logs and confirm that their authorization server returns the value.
SDKs reduce the work required for protocol upgrades
Alex says the MCP SDK teams put substantial effort into this release so client and server authors would not have to implement every protocol change themselves. He recommends using the SDK for the language in use instead of manually constructing messages. He specifically points to the Rust SDK 3.0.0, released on the day of the protocol release, and says the MCP SDK tiering process is intended to show how current and well-maintained each SDK is. The Rust SDK was being submitted for tier-one status.
"If you're building a program that does things with MCP, but you're manually sending messages or you're constructing the messages yourself for an update like this, you're going to have a lot of work to do if you don't use an SDK."14:43
Who should watch
You maintain an MCP server behind a load balancer and need to remove session pinning or a shared session store.
Your client or server uses elicitation, long-running work, or UI delivery and you need to understand the new extension patterns.
You are updating an MCP implementation by hand and want to judge whether the SDK for your language can absorb the protocol changes.
