MCP Versioning and Deprecation Policy

Status in the 2026-07-28 spec: core (version negotiation is required; the deprecation policy governs the spec itself)

MCP versions are dates, such as 2026-07-28, that mark the last time a backward-incompatible change was made. In the current spec, every request states the version it uses, and the server accepts or rejects each request on its own. Features are retired through a formal deprecation policy with a minimum twelve-month window.

Together, these rules tell you two things. Which version a client and server are speaking right now. And how much warning you get before a feature disappears.

This page covers both, using the versioning and compatibility page and the feature lifecycle and deprecation policy, as of October 2026.

What MCP versioning is

The versioning guide says MCP uses "string-based version identifiers following the format YYYY-MM-DD, to indicate the last date backwards incompatible changes were made." Backward-compatible updates do not bump the version.

Each revision has a label:

Why MCP needs both rules

MCP has thousands of independent clients and servers. They upgrade at different times. Versioning lets two programs agree on rules for each request. The deprecation policy gives builders a predictable runway before something is taken away.

The policy came with the 2026-07-28 release. The changelog lists it under governance updates, adopted through SEP-2596.

How version negotiation works

"There is no negotiation handshake," the versioning page says. "Every request carries its protocol version, and the server accepts or rejects each request independently."

The client sets io.modelcontextprotocol/protocolVersion in _meta. On HTTP the same value also goes in the MCP-Protocol-Version header. If the server does not support it, it "MUST respond with an UnsupportedProtocolVersionError listing the versions it does support." Here is the spec's example:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32022,
    "message": "Unsupported protocol version",
    "data": {
      "supported": ["2026-07-28", "2025-11-25"],
      "requested": "1900-01-01"
    }
  }
}

The client SHOULD pick a version from supported and retry, or show an error if none match. Clients that want to choose up front can call server/discover first.

Old and new versions side by side

The spec calls 2026-07-28 and later "modern," and 2025-11-25 and earlier "legacy," because those used an initialize handshake. An implementation that supports both is "dual-era." A server MAY serve both eras on the same endpoint. The versioning page includes a full compatibility matrix, and our specification changelog lists what each version changed.

How the deprecation policy works

The feature lifecycle policy defines three states:

A feature may be deprecated when something newer covers the same need, when it carries a risk that cannot be fixed in place, or when adoption is negligible compared with its upkeep. Each deprecation needs a SEP with a migration path and a window "at least twelve" months long. The window starts when the revision marking it deprecated is released.

Removal is not automatic. Core Maintainers decide during release preparation, and "features may remain Deprecated, without removal, for much longer than the minimum deprecation window."

The twelve-month floor can be shortened only for an "active security risk," such as a vulnerability with a published advisory and no in-place fix. Even then, the window must be "at least ninety days."

Tier 1 SDKs must mark deprecated features with their language's native deprecation tag in their next release, and should warn at runtime. See the official MCP SDKs for which SDKs are Tier 1.

What is deprecated as of October 2026

The deprecated features registry is the single list to check:

The registry also says: "No features have been removed under this policy yet."

What changed across spec versions

• 2025-06-18 and earlier: versions were agreed once in initialize. The 2025-06-18 release added the MCP-Protocol-Version HTTP header for later requests, per its changelog.
• 2025-11-25: the 2025-11-25 lifecycle page still required the client to send a version in initialize, with the server answering with the same or another version it supports.
• 2026-07-28: per-request versions, server/discover, the UnsupportedProtocolVersionError, the formal lifecycle policy and the deprecated registry.

Common mistakes

• Treating "deprecated" as "removed." Deprecated features still work. Plan the migration; do not panic.
• Treating "deprecated" as "fine forever." New implementations should not adopt them.
• Falling back to initialize on a modern error. If a server returns -32022, it is modern. Retry with a supported version instead.
• Reading a release date as the version. The version date marks the last breaking change, not necessarily the publish date.
• Expecting SDKs to drop features on the spec's schedule. The policy says SDK removal follows each SDK's own support policy.

Next step

See every version and its headline changes in MCP specification version history and changelog. For a governance view of upgrades, read MCP governance for IT leaders, or browse the MCP specification hub.

Frequently asked questions