Versioning and Compatibility changedspecification/draft/basic/versioning
Nearest release: v2.1.305, published under an hour before upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 20 Oct 2026 20:02 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 22 Oct 2026 20:37 UTC.
Upstream edited
Recorded here
Lines+6added
Lines−6removed
From line
76
where the diff opens
First seen
26 Aug 2026
this site's first read of the page
Recorded edits4to this page, all time
The whole hunk
from line 76, old and new numbered
/
from line 76
7676## Extension Negotiation
7777
7878Clients and servers can negotiate support for optional
79[extensions](/docs/extensions/overview) beyond the core protocol. Extensions
79[extensions](/docs/extensions/overview.md) beyond the core protocol. Extensions
8080are advertised in the `extensions` field of capabilities, which is a map of
8181extension identifiers to per-extension settings objects. Extension identifiers
8282**MUST** follow the [`_meta` key naming rules](/specification/draft/basic/index#meta),
from line 83
8383with a mandatory prefix.
8484
8585The following is an example of a client that advertises the
86[MCP Apps extension](/extensions/apps/overview) identified as `io.modelcontextprotocol/ui`:
86[MCP Apps extension](/extensions/apps/overview.md) identified as `io.modelcontextprotocol/ui`:
8787
8888```json theme={null}
8989{
from line 98
9898}
9999```
100100
101An example of [Tasks extension](/extensions/tasks/overview) identified as `io.modelcontextprotocol/tasks`:
101An example of [Tasks extension](/extensions/tasks/overview.md) identified as `io.modelcontextprotocol/tasks`:
102102
103103```json theme={null}
104104{
from line 129
129129server's era with transport-specific mechanics, specified in the binding
130130pages:
131131
132* [stdio](/specification/draft/basic/transports/stdio#backward-compatibility):
132* [stdio](/specification/draft/basic/transports/stdio.md#backward-compatibility):
133133 probe with `server/discover` and fall back on any error that is not a
134134 recognized modern error.
135* [Streamable HTTP](/specification/draft/basic/transports/streamable-http#backward-compatibility):
135* [Streamable HTTP](/specification/draft/basic/transports/streamable-http.md#backward-compatibility):
136136 attempt a modern request and inspect the body of a `400 Bad Request`
137137 before falling back.
138138
from line 163
163163| Modern | Legacy | Fails. The server may reject the request with an implementation-defined error, stay silent, or even process an era-ambiguous method under legacy semantics. On stdio, clients **SHOULD** send `server/discover` first to fail deterministically; the client then surfaces an actionable error to the user. |
164164| Dual-era | Modern | Works. The stdio probe returns a `DiscoverResult` (or `UnsupportedProtocolVersionError`); on HTTP, the first modern request succeeds or returns a modern error. The client stays modern. |
165165| Dual-era | Legacy | Works. stdio: the probe returns a non-modern error or times out, and the client falls back to `initialize`. HTTP: the modern request returns a `4xx` without a recognized modern error body, and the client falls back to `initialize` (and possibly further to the deprecated HTTP+SSE transport). |
166| Legacy | Modern | Fails. stdio: the server rejects `initialize` with a JSON-RPC error; the exact code is implementation-defined (`initialize` is an unknown method and the request also lacks the required `_meta` fields). HTTP: the request is missing the required headers and is rejected per [server validation](/specification/draft/basic/transports/streamable-http#server-validation) with `400 Bad Request` (a client on the deprecated HTTP+SSE transport fails at its opening `GET` instead). Legacy clients have no fall-forward mechanism. |
166| Legacy | Modern | Fails. stdio: the server rejects `initialize` with a JSON-RPC error; the exact code is implementation-defined (`initialize` is an unknown method and the request also lacks the required `_meta` fields). HTTP: the request is missing the required headers and is rejected per [server validation](/specification/draft/basic/transports/streamable-http.md#server-validation) with `400 Bad Request` (a client on the deprecated HTTP+SSE transport fails at its opening `GET` instead). Legacy clients have no fall-forward mechanism. |
167167| Legacy | Dual-era | Works. The server answers `initialize` and serves the client according to the negotiated legacy revision. |
168168| Legacy | Legacy | Works according to the legacy revision; out of scope for this document. |
169169
No line in this hunk matches that.