How should a client discover, select, cache, and fall back across MCP versions?

2026-07-28 core · deterministic JSON-RPC fixtures

Atlas Release Evidence Server. Read-only evidence, deterministic scoring, and an explicit evaluation Task across replicas and protocol eras.

01 · Smallest useful mechanism

Negotiate once, then keep era-specific semantics coherent.

Modern servers implement server/discover and every request declares a version. Unsupported versions return a dedicated error with supported versions. Legacy peers use initialize and session semantics.

A dual-era client needs an explicit probe and fallback strategy; it should not mix session and stateless assumptions.

02 · Experiment

Test the prediction

Deterministic protocol fixture

This workbench uses inspectable JSON-RPC fixtures and injected failures. It does not make live calls or execute external effects.

Protocol workbench · atlas-negotiation-v1

Choose a dual-era negotiation strategy for a mixed server fleet.

Injected failure

Discovery reaches a modern replica; the first domain request reaches a legacy replica.

Choose the implementation

Assume every server is modernSend domain work immediately with the newest metadata.Fallback after a failed domain callRetry the same effectful request using legacy initialize.Discover and bind coherentlyUse safe discovery/probe, bounded cache, and backend-consistent routing during negotiation.

The trace has not run.

Commit to an implementation, then inject the failure and inspect the actual state transitions.

03 · Implementation brief

Build it, break it, prove the outcome.

Implement: Build a negotiation matrix and safe probe for modern-only, legacy-only, and dual-era servers.
Break it on purpose: Change versions during rollout, poison the cache key, remove a common version, and attempt downgrade.
Completion evidence: No domain operation is duplicated, incompatible peers fail clearly, and cache/identity evidence explains every selection.

Your learning artifact

Write the argument you would defend

Stored only in this browser. No account required; course reset does not delete it.

Your response

04 · Check your understanding

What must a modern MCP server implement for compatibility discovery?

Primary sources · verified 2026-08-02

What the fixture does not prove

During migration, optimistic modern calls can hit legacy servers and cached conclusions can outlive deployments. Ambiguous fallback can duplicate operations or weaken security.

Common mistake: If JSON-RPC parsing succeeds, client and server are compatible. The same envelope can carry incompatible lifecycle, metadata, streaming, task, and capability semantics.

Transfer exercise: Probe a modern server, a legacy server, and a rolling deployment; define exactly when fallback is safe and when cache entries expire.

MCP — Versioning and compatibilityOfficial dual-era compatibility contract for modern and legacy peers, version errors, discovery, and fallback.MCP — Server discoveryNormative server/discover request, capability and identity response, and cache semantics.MCP — 2026-07-28 key changesOfficial migration summary covering session removal, discovery, MRTR, extensions, Tasks, caching, and deprecations.

Optional referenceDeep dive / reference chapterOpen the complete essay, diagrams, mathematics, exercises, glossary, and sources when you want more depth.on demand

Next: After compatibility is established, multi-round input and long-running Tasks can extend an operation without restoring hidden sessions.