Skip to content

Backwards compatibility & version negotiation #2892

Description

@maxisbey

Tracks: #2803

Make 2026-07-28 a real version the SDK can speak alongside every prior one: per-instance version knobs, the era classifier, and per-request _meta validation on the server. This is where the stateless server-side obligations land.

What's in it

  • Per-instance "what versions do I serve/speak" knobs (server + client); add 2026-07-28 to the negotiable set.
  • Era classifier + dispatch: server reads the _meta envelope (version/clientInfo/capabilities), validates it, emits the unsupported-version / missing-capability errors with typed data, and skips the legacy init gate for modern traffic.
  • Era-gate everything removed from core for modern peers: ping, logging/setLevel, roots/list_changed, the tasks surface, the URL-elicitation-required error.
  • resultType stamped on every modern result (the strip-for-legacy half is already in Protocol types for 2026-07-28: superset monolith, committed per-version packages, and wire-method maps #2849).

Conformance

  • (no scenario passes on this alone — it's the foundation the others stand on)
  • Together with New HTTP serving path (modern + dual-era), Capabilities API + server/discover handler, subscriptions/listen, Context object (layered, per-request): server-stateless
  • Together with New Client (all-versions, low-level + high-level) #2894: request-metadata

Dependencies

  • Depends on: none

References

Metadata

Metadata

Assignees

Labels

spec-2026-07-282026-07-28 MCP spec release workv2Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions