Versioning
The Model Context Protocol uses string-based version identifiers in the format YYYY-MM-DD, indicating the date of the last backwards-incompatible change.
Adapted from the official Versioning guide. Always confirm the live “current” revision on modelcontextprotocol.io.
Revisions
Revisions may be marked:
| State | Meaning |
|---|---|
| Draft | In progress — not ready for production consumption |
| Current | Ready for use; may still receive backwards-compatible changes |
| Final | Complete historical revision — frozen |
Check the official site for which revision is marked current. Docs in this playbook section follow the 2026-07-28 documentation path used by the upstream “getting started” tree.
Feature states
Individual features may be marked Deprecated under the feature lifecycle policy:
- Still part of the specification
- Scheduled for removal
- Migration path documented (or explicitly none)
- Remain at least twelve months (or ninety days under expedited-removal rules) before eligibility for Removed
See the deprecated features registry.
Negotiation
- Every request declares
io.modelcontextprotocol/protocolVersionin_meta. - On Streamable HTTP, the same value is also carried in the
MCP-Protocol-Versionheader. - Clients and servers MAY support multiple versions at once.
- If unsupported, the server returns
UnsupportedProtocolVersionErrorwith supported versions; the client retries or surfaces an error. - Optional up-front selection: call
server/discoverfor supported versions, capabilities and identity.
For handshake-based revisions (2025-11-25 and earlier), see Backward Compatibility in the specification.
Enterprise notes
- Pin supported versions in your platform standards document.
- Log version negotiation failures with server identity for supportability.
- Plan migrations when features you depend on appear in the deprecated registry (for example roots/sampling).
Discussion
Comments
Share feedback or questions about this page. No account required.
Loading comments…