Your MCP server faces a mixed client fleet — do you ship dual-era support, and for how long?

## The decision, framed correctly Revision 2026-07-28 removed the `initialize` handshake and protocol-level sessions and made MCP stateless: every request is self-contained and carries its own protocol version and capabilities, and servers must not rely on prior requests over the same connection to establish context. Handshake-era clients — 2025-11-25 and earlier — cannot be talked into that model, because there is no fall-forward: an old client opens with `initialize` and has no code path for per-request declaration. The only bridge is a server that implements both, and since servers are the component an operator can redeploy while clients live inside host applications on someone else's upgrade schedule, the burden lands on the server by default. That is the argument *for*. The judgment call is whether it is worth what it costs, and for how long. ## What dual-era actually costs - **Two lifecycles with contradictory rules.** One path establishes context once per connection; the other forbids relying on any prior request. Holding both correct in one codebase is the real expense. - **A doubled test matrix.** Every primitive has to be exercised under both models, and the interesting bugs live in the seam. - **A correctness trap, not just a cost.** The tempting shortcut is to let a modern request reuse capabilities the handshake negotiated. It passes tests on a single process and fails behind a load balancer, where any node may serve any request and the node holding that handshake is not the one that got this call. - **Surface area you must keep secure.** Mechanisms that only exist to serve old peers still have to be authorized, rate-limited and audited to the same standard as the ones you actually want. ## Decide on measurement, not on comfort The instinct is to support everything forever because compatibility feels responsible. Replace that instinct with data: - **Instrument by mechanism, not by claim.** Count requests by which lifecycle path served them. Client-reported identity is explicitly untrusted in the specification and is self-reported, so use it as a hint for outreach at most, never as the number a retirement decision rests on. - **Separate volume from importance.** A tail of legacy traffic from one integration you can contact is a phone call. The same volume spread across an unknown installed base is a real constraint. - **Watch the curve, not the level.** A legacy share that is falling steadily needs a date; one that is flat means clients are not upgrading and something other than time is required. ## Architecture: adapter in front, modern core behind If you carry it, contain it. Write the server modern-first — stateless, self-contained requests, state expressed as explicit server-minted handles passed as ordinary tool arguments — and put the legacy handshake in a translation layer at the edge. The adapter accepts the old opening exchange, holds whatever it must, and calls the same stateless core the modern path calls. Two properties follow: the core never learns that the old era exists, so it cannot accidentally depend on connection state; and retirement is a deletion at the edge rather than an untangling everywhere. The anti-pattern is era branches sprinkled through handlers. Those are the ones that survive their own retirement date, because nobody can prove which branches are dead. ## Announce the supported set, and mean it Whatever you decide, be legible to clients. The revisions you serve should be discoverable, and a request declaring one you will not serve should be rejected with `-32022` carrying `data.supported` and `data.requested`, so the client can pick something workable instead of failing blind. Publishing an honest set is what lets integrators plan, and it converts an outage into a retry. ## Roll uniformly A half-rolled fleet is worse than either end state. Because MCP is stateless and any node may serve any request, a client can get a modern result from one node and `-32022` from the next, which reads as flakiness and generates support load nobody can reproduce. Make the supported-version set identical across the fleet before advertising a change, and expect clients to cache an era verdict per server — they are entitled to, and a fleet that answers inconsistently punishes them for doing the right thing. ## Setting the end date Publish the retirement date when you ship the bridge, not when you are tired of it. A dated commitment converts an open-ended obligation into a plan, and it gives integrators the same courtesy the specification gives implementers when it guarantees a deprecated feature at least twelve months in the specification. Then hold to the plan: announce, watch the legacy share fall, contact the remaining identifiable callers, and cut on measured usage rather than on a calendar alone. If the number will not fall, the honest conclusion is that you have inherited a longer-lived obligation than you intended — and that is a fact to plan around, not to keep discovering every quarter. ## What a strong answer sounds like Refuse the false binary. Say that the answer depends on measured legacy traffic and on whether those clients are upgradable, that the bridge belongs in the server because that is the redeployable side, that it must be an edge adapter over a stateless core, that the fleet must roll uniformly, and that the commitment ships with a date attached. The candidates who have run this describe the load-balancer failure mode without being asked.