createmcps.com

Error

MCP error -32022: unsupported protocol version

Against MCP 2026-07-28 · verified 10 August 2026

The request is well-formed and its version is internally consistent — the server simply does not implement the revision being asked for. This is a negotiation outcome, not a malformed request.

The error

-32022 Unsupported protocol version

What causes it

Every 2026-07-28 request states its protocol revision twice: on the `MCP-Protocol-Version` header and in `params._meta.protocolVersion`. They must agree. If they do, and the value names a revision the server does not implement, the correct answer is -32022.

The usual cause is simply that one side upgraded. A client moved to 2026-07-28 while the server still implements 2025-11-25, or a server was pinned to a single supported version and a new revision shipped.

A subtler cause is a library floor you do not control. If your server is built on an SDK whose supported-version list stops before 2026-07-28, no amount of application code will make it accept that version — the check happens below you.

How to fix it

The fix

Check what your server actually claims to supportFind the supported-version list in your implementation and confirm 2026-07-28 is in it. If you are on an SDK, this is a property of the SDK build, not of your code, and upgrading the dependency is the only fix.

The fix

Distinguish -32022 from -32020 correctlyA missing version header is -32020. A header that disagrees with _meta is -32020. Only a consistent, well-formed version you do not implement is -32022. Getting this wrong sends people to debug the wrong half of their client.

The fix

Say which versions you DO supportThe error message is the only place a client can learn what would have worked. Name the supported revisions explicitly rather than returning a bare code.
An actionable -32022
{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32022,
    "message": "Unsupported protocol version 2026-07-28. This server supports: 2025-11-25",
    "data": { "supported": ["2025-11-25"] }
  }
}

The fix

Serve both revisions while you migrateThe two eras are distinguishable on arrival: a legacy client opens with an initialize handshake, a modern one sends params._meta and the required headers cold. Accepting both from one endpoint lets you move traffic without a flag day.

Rules involved

Each of these is checked against a live server, and each links to the exact sentence of the specification it comes from.

RuleWhat we checkLevelIf it fails
MCP-HDR-004Missing MCP-Protocol-Version rejected (modern-only servers)MUSTfail
MCP-HDR-005MCP-Protocol-Version header must match _meta.protocolVersionMUSTfail
MCP-DEP-001ping is no longer implementedMAYwarn

FAQ

Frequently asked

What is MCP error -32022?

It means the protocol revision the client requested is well-formed and consistent between header and body, but this server does not implement it. It is a negotiation result, not a malformed request.

How do I fix an unsupported protocol version error?

Establish which side is behind. If your server is older, add support for the requested revision — or, if you are on an SDK, upgrade it, because the supported-version list lives there and application code cannot override it. If your client is asking for a revision nothing implements yet, pin it to one the server advertises.

Can one MCP server support several protocol revisions?

Yes, and during a migration it is the right answer. Detect which era a request belongs to — a legacy client opens with initialize, a modern one sends params._meta with no handshake — and branch. Advertise every revision you accept in your error messages so clients can fall back.

Check this against your own server

Point the validator at a live MCP server and it reports every rule on this page as pass, warn or fail — each linked to the exact spec sentence it comes from.

Validate a server →