MCP protocol-version compatibility across current clients

Compatibility now has two protocol eras

The current MCP revision is 2026-07-28. It starts a modern, stateless era: clients no longer begin with `initialize`, and each request carries the protocol version, client identity, and capabilities in `_meta`. Streamable HTTP also carries the version in the `MCP-Protocol-Version` header. Servers advertise their supported revisions through `server/discover`.

Revisions through 2025-11-25 belong to the legacy era and open with an initialization handshake. A date string alone therefore does not describe compatibility. Record whether each client and server is modern-only, legacy-only, or dual-era, then record the exact build and transport that produced the result.

Legacy era

2024-10-07 through 2025-11-25A connection begins with `initialize` and keeps initialization-scoped identity and capabilities.

Modern era

2026-07-28 and laterRequests are self-contained; `server/discover` is available for up-front version selection.

Read the matrix before changing configuration

A modern client and modern server can proceed directly or retry after an `UnsupportedProtocolVersionError` lists mutually available revisions. A dual-era client can probe a modern server and remain modern, or identify a legacy server and fall back to `initialize`. A legacy client cannot fall forward to a modern-only server, and a modern-only client cannot use a legacy-only server.

That distinction prevents a common diagnosis error. A recognized modern protocol error means the server is modern but rejected that revision. For the official TypeScript SDK over HTTP, a 401 or 403 remains an authentication failure, a probe timeout remains a timeout, and an unreachable endpoint remains a connection failure; none triggers a legacy verdict. Preserve the status, JSON-RPC error, requested version, and supported-version list before attempting fallback.

Safest broad-compatibility target

Dual-era client plus dual-era serverBoth sides can select modern behavior while retaining an intentional legacy path.

Definitive mismatch

Legacy-only paired with modern-onlyOne side must be upgraded or configured for the other era; repeated reloads do not repair the wire contract.

What the current SDK acceptance tests actually prove

The official TypeScript SDK integration suite exercises wire-level behavior rather than only documenting it. Its HTTP fixtures verify an `auto` client probing with the 2026 revision, falling back cleanly to 2025, and removing modern-only headers after fallback. Separate cases keep HTTP 401 and 403 responses as authentication failures instead of misclassifying them as legacy-era evidence.

The stdio cases verify a disposable sibling probe, fallback after a silent legacy server times out, and a modern connection that reaches 2026-07-28 without sending either `server/discover` or `initialize` on the adopted session process. These tests substantiate the official SDK's negotiation behavior. They do not prove that Cursor, Claude, Windsurf, VS Code, or another branded client has enabled the same mode in a particular release.

Current package evidence stops short of acceptance

The version-pinned public `@offlinecreator/mcp` 0.1.2 package depends on `@modelcontextprotocol/server` 2.x, launches local stdio with `serveStdio`, and registers nine tools in its published server implementation. Those artifacts verify the package's declared server surface; they do not establish that 0.1.2 is the latest release or show which era a particular client build will negotiate.

The mandatory community-research run was blocked during credential preflight, and this pass did not execute a fresh protocol acceptance harness. Treat modern 2026-07-28 and legacy 2025-11-25 outcomes as unverified for package 0.1.2 until a dated, retained run records the client package version, Node version, operating system, transport, negotiated era, and discovered tool count.

Package under test

@offlinecreator/mcp@0.1.2Version-pinned public artifact accessed August 9, 2026; package inspection only.

Published stdio entry

serveStdioThe version-pinned entry point uses the official 2.x server package.

Published tool surface

9 registered toolsThis is code inspection, not a client discovery or end-to-end acceptance result.

Choose the next action from the observed era

If both endpoints are modern, retain the requested revision and validate one harmless discovery call. If a dual-era client falls back, record the legacy revision and confirm that modern-only features are not assumed. If a pin fails, compare the server's supported list before removing the pin. If the first response is 401 or 403, complete authorization first and re-probe; do not label the server legacy from an authentication wall.

Use the client directory for configuration syntax, the API-key fallback only when OAuth is unavailable, and the connection checklist to separate transport, authorization, discovery, and tool-call evidence.

Evidence limits and refresh boundary

The required August 9 refresh stopped before retrieval because the required research runtime credential was unavailable. This pass produced no current community items to assess, so it cannot establish whether discussion was active or quiet on any planned source and supplies no community evidence for a branded-client compatibility matrix.

The published compatibility guidance rests on the July 28 specification, immutable official TypeScript SDK documentation and integration tests, and current version-pinned OfflineCreator package artifacts. This pass did not complete package or branded-client protocol acceptance, remote OAuth, or any generation request, and no production credential was accessed. Refresh package versions, client builds, rollout notes, and the acceptance matrix monthly.