Negotiate a current MCP protocol version

What we checked

We asked your server which spec revision it speaks and compared the answer to the current spec. We probe server/discover first and read the newest version it advertises; if your server is on a pre-2026-07-28 revision we fall back to initialize and read the version it negotiates:

Implements a current MCP spec version

Implements a supported (recent but not the latest) MCP spec version

Implements an outdated MCP spec version; a newer spec is available

Why it matters

The protocol version decides which features both sides can use: new primitives and flows only light up when client and server both understand them.

How the version is agreed changed in the current revision. Up to 2025-11-25 the client proposed a protocolVersion in the initialize handshake and the server replied with the version it would actually speak. 2026-07-28 removed that handshake: every request now declares its version, and a server that cannot speak it replies with an UnsupportedProtocolVersionError naming the versions it supports.

Staying current keeps you compatible with the newest clients and unlocks the capabilities those clients expect. A server pinned to an old version still works, but it quietly opts out of everything added since, and risks falling out of support as clients drop old revisions.

Which MCP versions still get full marks?

At the time of writing, the current MCP spec revision is 2026-07-28. VerifyMCP gives full marks to that revision and the one immediately before it: the newest counts as running the current spec version, the previous revision (2025-11-25) still earns full marks (so you have a release cycle to upgrade before it slips), and anything older counts as an outdated spec version, with partial credit that falls off the further back you are.

How to fix it

In almost every case you don’t hardcode the version; the official SDK owns it, and upgrading the SDK is the fix. The SDK then reports the current protocol version for you, whichever way your revision does it: through server/discover on 2026-07-28 and later, or by negotiating it in the initialize handshake on earlier revisions.

# TypeScript - official MCP SDK
npm install @modelcontextprotocol/sdk@latest

# Python - official 'mcp' SDK
pip install --upgrade mcp
# or, with uv:
uv add mcp@latest

After upgrading, your server keeps the same shape; it just reports a newer version. The snippets below are minimal and conceptual; notice that neither pins a version string, because the SDK supplies it.

// @modelcontextprotocol/sdk - the SDK owns the protocol version for you.
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

const server = new McpServer({ name: "my-server", version: "1.0.0" });
// register tools/resources, then connect a transport.
// The SDK advertises the current protocol version it supports.

# Official 'mcp' SDK - the installed version determines the protocol revision.
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-server")
# define tools/resources, then run a transport.
# The SDK reports the current protocol version automatically.

How we re-check

We re-read the handshake on our next capture: a crawl for a hosted endpoint, or a fresh sandbox run of your published package. Once it reports a current spec version, the check records it as current on the following score refresh.

Give this to your AI

Paste this into Claude Code (or any coding agent) from inside your server's repository. It states the failing signal, the outcome we re-check for, and the format the fix has to take.

Prompt

Context: this repository publishes an MCP server, either as a hosted
endpoint or as a package on a registry such as npm or PyPI.
VerifyMCP's protocol version check failed, which means the spec
revision the server reports is older than the current one and the one
immediately before it, so the server is missing capabilities added
since.

Note that MCP 2026-07-28 removed the `initialize` handshake. A server on
that revision reports its versions through `server/discover` instead;
an older server still negotiates one in its `initialize` response.

Goal: the server reports a current spec revision, so the next capture
records a current version (or at minimum a supported one).

Do this:
1. Find where the official MCP SDK is declared (package.json,
   pyproject.toml, requirements.txt, go.mod) and check the installed
   version against the latest release.
2. Upgrade the SDK (`npm install @modelcontextprotocol/sdk@latest`, or
   `pip install --upgrade mcp` / `uv add mcp@latest`). Do not hand-write
   or hardcode a `protocolVersion` string anywhere in the handshake
   code; the SDK negotiates it for you.
3. Run the server locally and confirm the newer revision is reported -
   via `server/discover` (`supportedVersions`) on 2026-07-28 or later,
   or via the `initialize` response (`protocolVersion`) on an older
   revision.
4. Re-run your test suite: an SDK major bump can change other behaviour
   (transport wiring, capability shapes), not just the version string.

Rules:
- Never hardcode or spoof a newer protocol version than the server
  actually implements; the value must come from a real SDK upgrade, not
  a string edit.
- Moving to 2026-07-28 is a breaking wire change (no handshake, no
  sessions), not just a version bump. Check whether the clients you
  support can speak it before shipping.
- If the upgrade is a major SDK version bump, or would drop support for
  a spec feature your existing clients rely on, ask the human before
  shipping it.

Report back: the SDK version before and after, and the version field
from a live response proving it - `supportedVersions` from
`server/discover`, or `protocolVersion` from `initialize`.

Reference: https://verifymcp.io/docs/remote/protocol-version