Skip to content

Backwards compatibility & version negotiation #2892

@maxisbey

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
No fields configured for issues without a type.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions