What do modern, legacy and dual-era mean in MCP, and which combinations interoperate?

## Where the vocabulary comes from Revision 2026-07-28 made a change that cannot be papered over: it removed the `initialize` request and the `notifications/initialized` notification, removed protocol-level sessions, and declared MCP a stateless protocol in which "every request is self-contained and carries its own protocol version and capabilities". Everything before that revision worked the opposite way — you opened a connection, exchanged a handshake, and the negotiated result governed the traffic that followed. Because both designs are deployed at the same time, the ecosystem needs words for them: - **Modern** — implements the per-request metadata model. Revision 2026-07-28 and later. - **Legacy** — implements the `initialize` handshake model. Revision 2025-11-25 and earlier. - **Dual-era** — implements both, and can serve either kind of peer. ## Era belongs to the server The single most important framing point is that era is a property of the **server**, not of a request and not of a connection. A request declares a protocol version, but that declaration does not change what the server is: a legacy-only server does not become modern because a modern request arrived. It has one lifecycle model implemented in its code — or, if it is dual-era, two — and the client's job is to find out which before it builds any expectations. This matters for how you reason about a fleet. "Half our requests are modern" is a statement about traffic; "half our servers are legacy" is a statement about capability, and only the second one predicts what will fail. ## The compatibility matrix | Client | Legacy server | Modern server | Dual-era server | |---|---|---|---| | **Legacy** | works | fails | works | | **Modern** | fails | works | works | | **Dual-era** | works | works | works | Two cells deserve explanation. **Modern client, legacy server: fails.** The client sends a self-contained request with per-request metadata. The legacy server expects a handshake first and does not implement the modern discovery entry point at all, so the call does not land. The client can recover only by itself speaking the old model — that is, by being dual-era. **Legacy client, modern server: fails, and there is no fall-forward.** This is the asymmetry candidates miss. A modern server cannot rescue an old client, because the old client will open with `initialize`, a method the modern server no longer implements, and it has no code path for declaring version and capabilities per request. Compatibility cannot be pushed onto a peer that was compiled before the mechanism existed. The only fix is on the server side — be dual-era — or upgrade the client. So dual-era support is the only thing that actually bridges the gap, and in practice it is the servers that carry it, because servers are the side you can redeploy and clients are the side that lives in someone else's installed application. ## What dual-era costs A dual-era server is not a flag; it is two lifecycle implementations behind one surface. It must accept a handshake and hold the negotiated result for that connection *and* accept self-contained requests where nothing may be inferred from prior traffic. The stateless rule — servers must not rely on prior requests over the same connection to establish context — has to hold strictly on the modern path even while the legacy path does exactly the opposite. Test matrices double, and the temptation to let modern requests quietly reuse handshake state is a real correctness bug, because a load balancer may route the next request elsewhere. ## Practical guidance - Determine the server's era once, cache it per server, and drive everything from that decision. - Never infer a peer's era from a single successful call. One call succeeding tells you that call was acceptable; only a rejection with a supported-version list, or a discovery response, tells you the set. - When you write a new server today, write it modern-first and treat any legacy support as an adapter in front of it, so the stateless core is the thing that stays. - Deployment reality check: because a request declares its version but a server owns its era, a partially upgraded fleet produces intermittent, node-dependent failures for identical requests. Roll era support fleet-wide before you advertise it. ## Interview framing Give the three definitions with their revision boundaries, state that era is a server property, then draw the matrix and call out that there is no fall-forward. The candidates who have actually shipped against MCP in 2026 volunteer the last point without prompting, because it is the one that dictates who has to do the work: the server operator, not the client author.