A2A Blog/Alex/Sep 21, 2026

MCP Protocol Versions: What Does “MCP 2” Mean?

MCP protocol versions use dated specification revisions. Learn why MCP 2 may refer to an SDK, server release, or JSON-RPC 2.0 instead.

Diagram explaining mcp protocol versions with HTTP headers and Model Context Protocol specification details.

“MCP 2” does not identify an official protocol release by itself. As of September 20, 2026, the current MCP specification is the dated revision 2026-07-28. A number beginning with 2 may instead belong to an SDK, server, or JSON-RPC 2.0.

I’m Alex. When I review an upgrade, I first ask which component owns each number. Two components can display “2.0” while describing different layers. Use the record below before deciding whether a client and server are compatible.

Layer	Example label	What it identifies
MCP specification	`2026-07-28`	Rules used on the wire
SDK package	`2.x`	A language library release
MCP server	`1.2.3` or another declared string	One server implementation
JSON-RPC	`2.0`	The underlying request-and-response envelope

Does “MCP 2” Name an Official Protocol Release?

No. Current MCP specification revisions are identified by calendar-date strings, such as 2026-07-28, rather than names such as MCP 1 or MCP 2. The official 2026-07-28 release announcement calls that date the specification version.

Blog post overview showing updates to mcp protocol versions including stateless core and header-based routing.

Treat “MCP 2” as an incomplete label until its source is clear. For example, the Python SDK uses 2.x package releases while separately supporting dated protocol revisions. Upgrading that package does not automatically prove that every connected server speaks the same revision.

Which MCP Version Number Are You Looking At?

The first job is to attach the number to its owner. Record the component, exact version, source URL, and date checked.

MCP Specification Revision

The specification revision defines message fields, capabilities, errors, and compatibility rules. The 2026-07-28 revision replaced the earlier initialization handshake with per-request protocol metadata. That is a wire-level change, not a library marketing name.

SDK Package Version

An MCP SDK version describes a published software package. Each language SDK has its own release history. The Python SDK’s versioning policy, for example, uses semantic package versions and prerelease suffixes while tracking protocol support separately.

GitHub documentation page detailing semantic versioning policies for mcp protocol versions and package releases.

Check that SDK’s release notes and protocol-support page. Do not assume another language SDK with the same major number has identical behavior.

MCP Server Version

A server version identifies one implementation or package. The official Registry stores separate records for specific server versions. Its current schema recommends SemVer, allows non-semantic strings, and warns that they may not sort predictably.

Server version 2.0.0 therefore says nothing conclusive about its supported MCP revision. When choosing a business integration, compare its declared actions and maintenance as well as compatibility. Server selection is a separate decision from protocol compatibility.

JSON-RPC 2.0

MCP messages use the JSON-RPC 2.0 specification. The "jsonrpc": "2.0" member identifies that base envelope. It is not an MCP specification number, SDK release, or server version.

Sequence diagram illustrating request-response interactions across mcp protocol versions between model and server.

How Do Clients and Servers Check Protocol Compatibility?

They compare supported dated revisions and the capabilities required for the request. Matching package numbers are not the test.

Find the Declared or Negotiated Protocol Revision

Under MCP 2026-07-28, each request declares its revision in io.modelcontextprotocol/protocolVersion. Over HTTP, the protocol-version header must match it. A client may call server/discover to obtain the server’s supported revisions and capabilities. Earlier revisions can use initialization negotiation instead.

Inspect the actual request metadata or SDK diagnostics. A README badge or package number is not enough.

Compare Supported Revisions and Required Capabilities

A shared revision is only the first check. The client must also support the capabilities, extensions, transport behavior, and tools needed by the workflow. A server can speak the right core revision yet lack a required optional extension.

For a practical example, an X Ads MCP workflow should verify the server’s declared actions and approval path rather than infer them from its version label.

Check Compatibility Before You Upgrade

Create a short inventory, then test the combination you will actually deploy. Documentation for one layer cannot certify the others.

Architecture diagram comparing load balancing changes across mcp protocol versions from 2025-11-25 to 2026-07-28.

Identify Every Version Layer

Record the client application, SDK package, MCP revision, server release, transport, and enabled extensions. Add authentication scopes and any gateway that can rewrite headers. Keep the evidence URL beside each entry.

Test the Client and Server Together

Use a staging account and one reversible tool call. Confirm discovery or negotiation, capability handling, error output, and logs. Then test an unsupported revision and a missing capability. Save the observed request and response with secrets removed.

What Goes Wrong When Version Labels Are Mixed Up?

Teams may upgrade the wrong component, report a false compatibility problem, or enable a feature that the peer never advertised. They may also treat an SDK prerelease as a new protocol standard.

The repair is simple: rewrite each claim as “component + version + supported protocol revision.” “Python SDK 2.x supports revision 2026-07-28” is testable. “We support MCP 2” is not.

FAQ

Can an MCP Registry server version use calendar dates instead of SemVer?

Yes, the current Registry schema allows non-semantic server version strings, although it recommends SemVer and warns that other formats may sort unpredictably. A calendar date in a server record still identifies that server release unless the publisher explicitly documents another meaning. See the official server schema.

Do prerelease MCP SDKs support the same protocol revisions as stable releases?

Not necessarily. A prerelease can add, change, or stage protocol support before a stable package does. Check the exact SDK’s release notes and support matrix; Python’s official protocol-version notes keep package and protocol versions distinct.

Can MCP extensions use versions independent of the core specification?

Yes. Official extensions evolve independently, and implementations advertise support through capabilities. Core revision compatibility does not establish extension compatibility. The official extensions proposal says extensions should be versioned, while leaving the precise method to each extension.

What HTTP status should a server return for an unsupported MCP protocol version?

For the current 2026-07-28 Streamable HTTP behavior, official TypeScript SDK guidance uses the MCP JSON-RPC error -32022, UnsupportedProtocolVersion. Earlier revisions or other modes of transport may differ, so follow the applicable transport and revision documentation. See the official SDK migration guidance.

Can JSON-RPC 2.0 support batching when an MCP revision does not?

JSON-RPC 2.0 defines batch requests, but that does not make batching valid for every protocol built on it. The MCP revision and transport rules govern MCP behavior. Follow the narrower MCP contract even when the base JSON-RPC specification permits a broader pattern.

Conclusion

Read every version number with its layer attached. Dated MCP specification versions describe the wire contract; SDK and server versions describe implementations; JSON-RPC 2.0 describes the envelope.

Before upgrading, record all four, verify capabilities, and test the real client-server pair. That turns “MCP 2” from an ambiguous label into a compatibility question your team can answer.