modelcontextprotocol · mcp-commander · Jun 5, 2026 · Jun 5, 2026 · Jun 5, 2026 · Jun 5, 2026
@@ -112,6 +112,9 @@ released as Current, Tier 1 SDKs:
   `DeprecationWarning`, Node.js's `process.emitWarning`, or a configurable
   logger).
 
+A Tier 1 SDK that consistently fails to surface a Deprecated feature is subject to the
+[Tier Relegation Process](/community/sdk-tiers#tier-relegation).
+
 ## Removing a Feature
 
 1. Once a feature is set for removal, the removal is executed at the discretion
@@ -122,6 +125,8 @@ released as Current, Tier 1 SDKs:
    ([Expedited removal](#expedited-removal)) or restoring the feature to Active
    ([Feature states](#feature-states)).
 
+Features may remain Deprecated, without removal, for much longer than the minimum deprecation window.
+
 ## Expedited Removal
 
 The twelve-month floor may be shortened when the feature presents an active
@@ -133,3 +138,17 @@ in the deprecation SEP or, where the risk surfaces after that SEP is already
 Final, in a short expedited-removal SEP that references it. The shortened
 window must still provide at least ninety days between the feature becoming
 Deprecated and its earliest removal.
+
+## Roles
+
+| Action                                         | Who                                                                                             |
+| ---------------------------------------------- | ----------------------------------------------------------------------------------------------- |
+| Propose deprecation, extension, or restoration | Any contributor, per the SEP process                                                            |
+| Sponsor                                        | A Maintainer or Core Maintainer, per the SEP process                                            |
+| Approve a deprecation SEP                      | Core Maintainers, per the [governance decision process](/community/governance#decision-process) |
+| Decide a removal during release preparation    | Core Maintainers, per the [governance decision process](/community/governance#decision-process) |
+| Approve an extension or restoration SEP        | Core Maintainers, per the [governance decision process](/community/governance#decision-process) |
+| Approve expedited removal                      | Core Maintainers, per the [governance decision process](/community/governance#decision-process) |
+
+Lead Maintainers retain veto authority over each of the approvals
+above, per the [governance roles](/community/governance#roles) definition.
@@ -72,6 +72,7 @@ Conformance scores are calculated against **applicable required tests** only:
 - Excluding tests marked as pending or skipped
 - Excluding tests for experimental features
 - Excluding legacy backward-compatibility tests (unless the SDK claims legacy support)
+- Excluding tests labeled `disputed` in the conformance repository, until the dispute is resolved
 
 Conformance testing validates that SDKs correctly implement the protocol by running standardized test
 scenarios and checking protocol message exchanges. See [Tier Relegation](#tier-relegation) for how
@@ -96,6 +97,8 @@ continuously for 4 weeks:
 - **Tier 1 → Tier 2**: Any conformance test fails
 - **Tier 2 → Tier 3**: More than 20% of conformance tests fail
 
+An SDK may also be relegated if issues remain unaddressed for two months.
+
 ## Issue Triage Labels
 
 SDK repositories must use consistent labels to enable automated reporting on issue handling metrics.

@@ -35,11 +35,12 @@ Not sure? Ask in [Discord](/community/communication#discord) before starting sig
 
 ## SEP Types
 
-There are three kinds of SEP:
+There are four kinds of SEP:
 
 1. **Standards Track** - Describes a new feature or implementation for the Model Context Protocol, or an interoperability standard supported outside the core specification.
 2. **Informational** - Describes a design issue or provides guidelines/information to the community without proposing a new feature.
 3. **Process** - Describes a process surrounding MCP or proposes a change to a process (like this document).
+4. **Extensions Track** - Describes a protocol extension. Follows the same review and acceptance process as Standards Track SEPs, but indicates that the proposal is for an extension rather than a protocol addition. See [Creating Extensions](/extensions/overview#creating-extensions) for the extension lifecycle.
 
 ## SEP Workflow
 

@@ -7,7 +7,7 @@ description: Optional extensions to the Model Context Protocol
 
 MCP extensions are optional additions to the specification that define capabilities beyond the core protocol. Extensions enable functionality that may be modular (e.g., distinct features like authentication), specialized (e.g., industry-specific logic), or experimental (e.g., features being incubated for potential core inclusion).
 
-Extensions are identified using a unique _extension identifier_ with the format: `{vendor-prefix}/{extension-name}`, e.g. `io.modelcontextprotocol/oauth-client-credentials`. Official extensions use the `io.modelcontextprotocol` vendor prefix.
+Extensions are identified using a unique _extension identifier_ with the format: `{vendor-prefix}/{extension-name}`, e.g. `io.modelcontextprotocol/oauth-client-credentials`. Identifiers follow the same rules as [`_meta` keys](/specification/draft/basic/index#meta), with a mandatory prefix. Official extensions use the `io.modelcontextprotocol` vendor prefix.
 
 <Tip>
 

@@ -135,7 +135,7 @@ state does not change.
 
 ## Notifications
 
-Servers can push status updates via `notifications/tasks/status`. Clients opt
+Servers can push status updates via `notifications/tasks`. Clients opt
 into these through the `subscriptions/listen` mechanism. Each notification
 carries the full task state, eliminating the need for an extra `tasks/get`
 round-trip.

@@ -246,6 +246,27 @@ MCP supports JSON Schema with the following rules:
 
 - Schemas **MUST** be valid according to their declared or default dialect
 
+### `$ref` Resolution
+
+JSON Schema 2020-12 permits `$ref` to point at an absolute URI. Implementations **MUST NOT**
+automatically dereference `$ref` values that resolve to a network URI.
+
+Implementations **MAY** offer an opt-in mode that fetches non-local `$ref`s but it
+**MUST** be disabled by default and **SHOULD** enforce an allowlist of hosts or at
+minimum reject loopback, link-local, and private network addresses, apply timeouts and
+size limits, and log dereferenced URIs.
+
+Schemas that fail to validate due to an unresolved external `$ref` **SHOULD** be rejected
+rather than silently treated as permissive.
+
+### Composition-Keyword Resource Use
+
+Composition keywords (`anyOf`, `oneOf`, `allOf`, `if`/`then`/`else`) and `$defs` enable
+expressive schemas but can be expensive to validate. Implementations **SHOULD** apply
+reasonable bounds, such as a maximum schema depth, a cap on the total number of subschemas,
+or a per-validation time budget, to prevent a malicious schema from acting as a Denial-of-Service
+vector against the validator.
+
 ## General fields
 
 ### `_meta`
@@ -289,6 +310,10 @@ without relying on any prior connection state. See
 | `io.modelcontextprotocol/clientCapabilities` | `ClientCapabilities` | Yes      | Client capabilities relevant to this request              |
 | `io.modelcontextprotocol/logLevel`           | `LoggingLevel`       | No       | Minimum log level the server should emit for this request |
 
+A request missing any required field is malformed; the server **MUST** reject it with
+JSON-RPC error code `-32602` (Invalid params). On HTTP, the response status **MUST** be
+`400 Bad Request`.
+
 A server **MUST NOT** rely on capabilities the client has not declared. If
 processing a request requires a capability the client did not include in
 `io.modelcontextprotocol/clientCapabilities`, the server **MUST** return a

@@ -110,9 +110,10 @@ them.
 A subscription ends when:
 
 - The **client** cancels it — close the SSE stream (HTTP) or send
-  `notifications/cancelled` referencing the listen request ID (stdio).
-- The **server** tears it down (e.g., during shutdown) — it closes the
-  underlying transport connection.
+  `notifications/cancelled` referencing the `subscriptions/listen` request ID (stdio).
+- The **server** tears it down (e.g., during shutdown) — it **MUST** close the SSE
+  stream (HTTP) or send `notifications/cancelled` referencing the
+  `subscriptions/listen` request ID (stdio).
 - The underlying transport closes (HTTP timeout, TCP disconnect, stdio process
   exit).
 

@@ -547,7 +547,7 @@ header value and the body value numerically rather than as strings (e.g.,
 </Note>
 
 When rejecting a request due to header validation failure, servers **MUST**
-return HTTP status `400 Bad Request` and **SHOULD** include a JSON-RPC error
+return HTTP status `400 Bad Request` and **MUST** include a JSON-RPC error
 response using the following error code:
 
 | Code     | Name             | Description                                                                                                            |

@@ -82,7 +82,9 @@ preferred version is not supported.
 Clients and servers can negotiate support for optional
 [extensions](/docs/extensions/overview) beyond the core protocol. Extensions
 are advertised in the `extensions` field of capabilities, which is a map of
-extension identifiers to per-extension settings objects.
+extension identifiers to per-extension settings objects. Extension identifiers
+**MUST** follow the [`_meta` key naming rules](/specification/draft/basic/index#meta),
+with a mandatory prefix.
 
 The following is an example of a client that advertises the
 [MCP Apps extension](/extensions/apps/overview) identified as `io.modelcontextprotocol/ui`:
@@ -149,20 +151,25 @@ process (stdio) or origin (HTTP), and **MAY** persist it across restarts of
 the same server configuration, re-probing if the cached assumption later
 fails.
 
+A server that supports only [modern](#terminology) versions **SHOULD** name
+the protocol versions it supports in any error it returns to an `initialize`
+request, on any transport: legacy clients have no fall-forward mechanism, and
+this message may be the only diagnostic they can surface to users.
+
 ### Compatibility Matrix
 
 The following matrix summarizes the expected outcome of every combination of
 client and server era:
 
-| Client   | Server   | Outcome                                                                                                                                                                                                                                                                                                                                         |
-| -------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Modern   | Modern   | Works. `server/discover` is optional; version mismatches surface as `UnsupportedProtocolVersionError` and the client retries with a mutually supported version.                                                                                                                                                                                 |
-| 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.                                      |
-| 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.                                                                                                                                                        |
-| 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).                                             |
-| Legacy   | Modern   | Fails. `initialize` is an unknown method: the server returns `Method not found` (`-32601`); on HTTP this is a `404` with the JSON-RPC error in the body. Legacy clients have no fall-forward mechanism. Modern servers **SHOULD** include an error message naming the protocol versions they support, since legacy clients surface it to users. |
-| Legacy   | Dual-era | Works. The server answers `initialize` and serves the client according to the negotiated legacy revision.                                                                                                                                                                                                                                       |
-| Legacy   | Legacy   | Works according to the legacy revision; out of scope for this document.                                                                                                                                                                                                                                                                         |
+| Client   | Server   | Outcome                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| -------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Modern   | Modern   | Works. `server/discover` is optional; version mismatches surface as `UnsupportedProtocolVersionError` and the client retries with a mutually supported version.                                                                                                                                                                                                                                                                                                                                                                        |
+| 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.                                                                                                                                                                                                                             |
+| 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.                                                                                                                                                                                                                                                                                                                                               |
+| 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).                                                                                                                                                                                                                                    |
+| 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. |
+| Legacy   | Dual-era | Works. The server answers `initialize` and serves the client according to the negotiated legacy revision.                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| Legacy   | Legacy   | Works according to the legacy revision; out of scope for this document.                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
 
 A dual-era **server** selects its behavior from how the client opens:
 

@@ -42,6 +42,10 @@ the previous revision, [2025-11-25](/specification/2025-11-25).
    clients **MUST** key persisted credentials by the issuer identifier, **MUST NOT** reuse them
    with a different authorization server, and **MUST** re-register when the authorization server
    changes ([SEP-2352](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2352)).
+10. Loosen `inputSchema` and `outputSchema` to allow any JSON Schema 2020-12 keywords, and
+    `structuredContent` to allow any JSON value. Add `$ref` resolution requirements and
+    composition-keyword resource bounds
+    ([SEP-2106](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2106)).
 
 ## Deprecated
-Original file line number
+Diff line change
@@ Expand Up / @@ -7,7 +7,7 @@ description: Optional extensions to the Model Context Protocol @@
     MCP extensions are optional additions to the specification that define capabilities beyond the core protocol. Extensions enable functionality that may be modular (e.g., distinct features like authentication), specialized (e.g., industry-specific logic), or experimental (e.g., features being incubated for potential core inclusion).
-    Extensions are identified using a unique _extension identifier_ with the format: `{vendor-prefix}/{extension-name}`, e.g. `io.modelcontextprotocol/oauth-client-credentials`. Official extensions use the `io.modelcontextprotocol` vendor prefix.
+    Extensions are identified using a unique _extension identifier_ with the format: `{vendor-prefix}/{extension-name}`, e.g. `io.modelcontextprotocol/oauth-client-credentials`. Identifiers follow the same rules as [`_meta` keys](/specification/draft/basic/index#meta), with a mandatory prefix. Official extensions use the `io.modelcontextprotocol` vendor prefix.
     <Tip>
@@ Expand Down @@