MCP 728 changes the protocol from stateful sessions to a stateless design, which makes servers easier to scale across replicas.
2
Teams have a 12-month migration period, during which they can run modern and legacy versions together or place a compatibility runtime between them.
3
Server callbacks, Roots, Sampling, older transport options, and other features are being deprecated or moved into extensions, so clients and servers need different migration work.
Summary
Mateo Torres explains MCP 728 as the largest rewrite of the protocol since its launch. The central change is a move from stateful sessions to stateless requests. Requests carry the context a server needs, so any replica can handle them and a failed replica does not take the session with it. This simplifies server scaling, although it makes client implementations more involved. Servers and clients can move directly to the modern version, support both versions during the transition, or use a runtime layer that translates between legacy and modern peers. The release also removes server callbacks, changes streaming and transport behavior, makes discovery and caching more explicit, and moves capabilities such as tasks into extensions. Mateo describes a 12-month migration window and gives practical advice for teams that do not control every client or server they depend on. He says server developers are likely to benefit first, while client developers have more compatibility work.
MCP 728 makes requests stateless so replicas can share work
In the legacy design, a sticky load balancer binds a client session to one server replica. Adding replicas does not help that client, and losing its assigned replica loses the session state. In the modern design, each request carries the information the server needs to respond. Any replica can handle any request, new replicas join the available pool, and a client can continue after one or two replicas fail. Mateo presents this as the main operational benefit of MCP 728.
Servers can move directly to modern MCP or support both versions
A server can drop the stateful implementation and adopt the stateless protocol, or it can run as a dual-version server from the same endpoint. The dual-version option checks how the client initiates contact and then uses the modern or legacy mode. Mateo says this is harder to implement, but it gives a server access to both kinds of clients during the transition. Teams that change nothing may continue working temporarily, although popular clients are expected to move to the modern version.
Clients face a compatibility matrix during the migration
A modern client can communicate with modern and legacy servers when it supports both modes. A legacy client cannot communicate with a modern server, and a legacy server cannot communicate with a modern client that only speaks the new protocol. Mateo recommends probing a configured server for modern support and falling back to the legacy initialization path when needed. Teams that do not control all of their servers may need a dual-version runtime in the middle.
A compatibility runtime can translate between legacy clients and modern servers
Mateo describes a gateway pattern for the transition period. A legacy client connects to one side of the gateway, which speaks the legacy protocol. A modern server connects to the other side, and the gateway speaks the modern protocol there. This handles many general compatibility cases, though it cannot translate features that have no equivalent or that depend on deprecated behavior. He recommends using this pattern when a team must support older clients or servers it does not maintain.
Server callbacks and several stateful patterns are removed
In the old protocol, a server could send a message back to the client when work produced an update. MCP 728 removes that server-to-client callback pattern. The client must retry or reopen requests, and the protocol uses other request patterns to preserve statelessness. Streaming is also restructured around a single channel. Older stream and subscription behavior changes, so clients need to restart or request streams again when the server indicates that they have changed.
Discovery, caching, and extensions take on larger roles
Servers must advertise their identity and capabilities through discovery, allowing clients to inspect what a server supports before negotiating further. Caching becomes a first-class pattern through leases for tool definitions and other keys. A client can reuse cached information until the server invalidates the lease. Tasks move out of the core specification and into extensions. Mateo says extensions are independently versioned and identified by reverse-domain names, so new features can develop without changing the base protocol.
The migration window gives teams one year to update
Mateo describes a 12-month period before legacy features are removed. He advises teams to identify whether their servers rely on features such as Roots, Sampling, older notification behavior, or older transport options. His recommendations include passing files and directories through parameters or resource URIs, moving model-related work to the appropriate server-side pattern, and using Streamable HTTP as the official remote transport. Teams need to decide whether to maintain dual support or put the translation work in a runtime.
Server developers gain simplicity while client developers take on more work
Mateo says the new specification makes servers easier to implement and scale because they no longer manage stateful sessions in the same way. Client implementations become somewhat more complicated because they need discovery, negotiation, caching, fallback behavior, and possibly support for both protocol versions. He says the available inspector, MCP Jam, SDKs, and frameworks already support the new specification, which gives teams tools for testing during the migration.
