A server operator must move to revision 2026-07-28 but still serve older clients that open with an initialize handshake. Which design lets one server handle both kinds of clients?
Select an answer to reveal the explanation.
Short Explanation
You run a bilingual front desk. A visitor who opens with the old handshake gets the old conversation, and one who shows up with modern _meta gets served statelessly. Refusing the old-timers strands them, and staying legacy-only strands modern-only clients.
Full Explanation
The versioning page calls an implementation that supports both modern and legacy versions dual-era. A dual-era server selects its behavior from how the client opens: a request carrying modern per-request _meta is served statelessly under 2026-07-28, while an initialize request selects legacy semantics scoped to the stdio process or the HTTP session, according to the negotiated legacy version; it may serve both eras concurrently on the same endpoint. The compatibility matrix confirms a legacy client with a dual-era server works. Refusing initialize turns the server into a modern-only server, and legacy clients have no fall-forward mechanism, so they would simply fail. Minting Mcp-Session-Id values for modern clients reintroduces sessions that 2026-07-28 removed; modern clients do not use them and modern-only servers ignore the header. Staying legacy-only fails modern-only clients, since the matrix lists modern client to legacy server as a failure; only dual-era clients fall back to initialize. Exam caveat: a modern-only server SHOULD name its supported protocol versions in any error it returns to initialize, because that message may be the only diagnostic a legacy client can show. Operational check: connect one legacy client and one modern client to the server at the same time and confirm both complete tool calls.