Zuplo

Versions and governance

How revisions are numbered, how features are retired, and how any of it changes.

Protocol revision

MCP versions are dates in YYYY-MM-DD form, naming the last date on which backward-incompatible changes were made. #

MCP versions are dates in YYYY-MM-DD form, naming the last date on which backward-incompatible changes were made. A revision is marked Draft, Current, or Final; the current revision is 2026-07-28. The version is not incremented for backward-compatible changes.

Where you meet it

Every revision keeps its own permanent documentation tree, so a search result can land you on guidance three revisions old with no warning on the page. Check the date in the URL before trusting anything you read about MCP.

Also written: protocol revision · MCP version · 2026-07-28 · protocol version · Draft Current Final

Source: MCP: Versioning
Read next: MCP-Protocol-Version Deprecated, Removed, and Active SEP

Deprecated, Removed, and Active

The feature lifecycle policy puts every specification feature in exactly one of three states. #

The feature lifecycle policy puts every specification feature in exactly one of three states. Active means implement it. Deprecated means it stays in the specification with a documented migration path, and new implementations should not adopt it. Removed means it has been deleted from the draft and will be absent from the next Current revision.

Where you meet it

A Deprecated feature must stay put for at least twelve months from the revision that deprecated it — or ninety days under the security-driven expedited exception — before it is even eligible for removal, and it may stay far longer. No feature has yet reached the Removed state, which is why sessions and the initialize handshake are a separate case: 2026-07-28 deleted them outright as a breaking change rather than deprecating them first.

Also written: deprecated · removed · feature lifecycle · deprecation policy · deprecated features registry · SEP-2596

Source: MCP: Feature Lifecycle and Deprecation Policy MCP 2026-07-28: Deprecated features registry
Read next: DCR Sampling Roots HTTP+SSE transport Mcp-Session-Id

Official extension

Changed in 2026-07-28 An optional addition to the specification that defines capability beyond the core protocol, identified as {vendor-prefix}/{extension-name}. #

An optional addition to the specification that defines capability beyond the core protocol, identified as {vendor-prefix}/{extension-name}. Official extensions use the io.modelcontextprotocol vendor prefix and live in ext--prefixed repositories in the Model Context Protocol GitHub organization. There are four: io.modelcontextprotocol/ui (MCP Apps), io.modelcontextprotocol/tasks (Tasks), io.modelcontextprotocol/oauth-client-credentials, and io.modelcontextprotocol/enterprise-managed-authorization.

Tasks moved out of the core protocol into an extension in this revision (SEP-2663). Two sources differ on its standing: the extensions overview lists Tasks among the official extension repositories, while the ext-tasks repository README labels itself experimental and says it is not an official extension.

Where you meet it

Both sides advertise support in the extensions field of their capabilities — clients inside io.modelcontextprotocol/clientCapabilities, servers in the server/discover response — and each extension defines its own settings object. Extensions are always off by default. If one side supports an extension and the other does not, the supporting side must fall back to core behavior or reject the request.

Also written: official extensions · MCP extensions · io.modelcontextprotocol/ui · io.modelcontextprotocol/tasks · io.modelcontextprotocol/oauth-client-credentials · io.modelcontextprotocol/enterprise-managed-authorization · MCP Apps · extensions capability

Source: MCP: Extensions Overview MCP: Extension Support Matrix
Read next: _meta server/discover SEP

Specification Enhancement Proposal

SEP A SEP is a design document that describes a new feature for MCP or for its processes, and it is the mechanism required for any protocol change, breaking change, or governance change. #

A SEP is a design document that describes a new feature for MCP or for its processes, and it is the mechanism required for any protocol change, breaking change, or governance change. SEPs are numbered by the pull request that introduces them and published in the specification repository.

Where you meet it

Every change described on this page traces to one, which makes a SEP number the most precise citation available for an MCP claim. Statelessness is SEP-2567 and SEP-2575, MRTR is SEP-2322, the deprecation policy is SEP-2596, and the sampling and roots deprecations are SEP-2577.

Also written: SEP · specification enhancement proposal · SEP-2575 · SEP-2322

Source: MCP: SEP Guidelines
Read next: Protocol revision Deprecated, Removed, and Active