Skip to main content
The inspector can speak more than one version of the MCP protocol. By default (Automatic), unpinned connections probe server/discover for 2026 support and fall back to the legacy initialize negotiation — on both HTTP and stdio. You can also pin a specific version when you want to test an exact revision — including the 2026-07-28 stateless RC or any earlier stable release.
Migration required if you used the old Draft version. The previous DRAFT-2026-v1 placeholder has been retired and replaced with the upstream RC literal 2026-07-28. If you had any servers pinned to DRAFT-2026-v1, you must re-select the protocol version in the inspector UI. Stored DRAFT-2026-v1 pins are rejected by spec-conforming servers with a -32004 UnsupportedProtocolVersionError.

​
Where the setting lives

There are three places to set a version, and they layer:
  1. Client → MCP Protocol — the host default applied to every server attached to that Client.
  2. Add Server modal → Connection overrides → Protocol version — a per-server override set at add time (available when adding a server to a shared project).
  3. Server card → Edit → Advanced settings → Protocol version — a per-server override that wins over the host default.
Use the host default when you want every server in a Client to speak the same version. Use per-server overrides when you’re testing a mix — for example, a November server alongside one you’re upgrading to Latest.

​
Available versions

​
Host default (client-level) dropdown

Automatic stores no pin — the absence of a pin is the meaning, not a hidden default. Picking any other option stores that exact version literal and narrows the initialize handshake’s accept-list to that single revision. When Automatic falls back to the legacy initialize handshake, it uses the MCP SDK’s complete built-in supported-version list. Persisted per-client accept-lists are ignored in Automatic mode so reconnecting cannot accidentally narrow negotiation; choose an explicit version when you want a strict protocol pin. Latest is derived, not hardcoded: it always labels the newest version in the SDK’s known-version list. November labels the 2025-11-25 stateful release. The 2026 RC applies the stateless model across transports. MCPJam’s initial preview client is narrower: it currently supports the RC over Streamable HTTP POST. The per-server dropdown hides the RC option for STDIO and legacy SSE servers; if a host-level RC default reaches a non-HTTP server, the inspector fails the connection with a clear transport error instead of silently attempting the wrong protocol.

​
Setting the host default

Client editor with the MCP Protocol tab open and the Protocol version dropdown showing Automatic, Latest (2026-07-28), November (2025-11-25), 2025-06-18, and 2025-03-26 options
  1. Open the Clients tab.
  2. Pick the Client you want to edit (or create a new one).
  3. Open the MCP Protocol tab.
  4. In the Protocol version dropdown, pick a version:
    • Automatic — no pin stored; the SDK picks the version at connect time (default).
    • Latest (2026-07-28) — pin to the newest stateless revision.
    • November (2025-11-25) — pin to the November stateful release.
    • 2025-06-18 or 2025-03-26 — pin to an earlier stable revision.
  5. Save.
Every server attached to this Client now connects with that version unless it has its own per-server override. A helper note appears below the dropdown whenever a version is pinned, describing what the pin stores.

​
Overriding a single server

You can set the per-server protocol version either when adding a server or when editing an existing one.

​
At add time (shared projects)

When adding a server to a shared project, the Connection overrides section of the Add Server modal includes a Protocol version picker. The 2026 RC option is only shown for HTTP servers.
  1. Click Add server in the Servers tab.
  2. Fill in the server details.
  3. Expand Connection overrides.
  4. Pick Client default, Latest (2026-07-28), November (2025-11-25), or an earlier stable revision from the Protocol version dropdown.
  5. Submit the form.
The pin is applied once the server is created and the connection is established.

​
After adding (edit flow)

  1. Go to the Servers tab.
  2. Click the three dots on the server card → Edit (or open View server info → Edit).
  3. Expand Advanced settings.
  4. Find Protocol version and pick Host default, Latest (2026-07-28), November (2025-11-25), or an earlier stable revision.
  5. Save and reconnect the server.
The per-server override is the more specific signal — it wins over whatever the Client’s MCP Protocol tab says.

​
OAuth protocol alignment with MCP negotiation

When you add or edit an HTTP server with OAuth 2.0 authentication, the Authentication → Advanced → Protocol dropdown lets you choose which OAuth spec era the connect flow uses. The default is Auto. Auto is stored as intent; it is not converted into a permanent concrete pin when you save the server. Each OAuth flow resolves and records one concrete version in this order:
  1. An explicit OAuth protocol selection.
  2. An explicit per-server or host MCP wire pin.
  3. The version freshly detected or negotiated with the MCP server.
  4. 2025-11-25 when a 401 requires OAuth before the server can provide protocol evidence.
The last case is an authentication-gated compatibility fallback, not version detection. If you know an auth-gated server requires the 2026 draft behavior, select 2026-07-28 explicitly. OAuth callback security follows the concrete version recorded for that flow. Every version validates state. The 2026-07-28 flow also validates a returned RFC 9207 iss against the discovered authorization-server issuer; 2025 flows retain compatibility and ignore callback iss.

​
What changes when you pick Latest (2026-07-28)

If your server already speaks 2026-07-28, you mostly won’t notice. A few things to know when you’re testing:
  • No initialize handshake. The inspector connects, immediately fires server/discover, and uses the result to populate the server card’s name, version, capabilities, and instructions.
  • Per-request metadata. Every request the inspector sends carries MCP-Protocol-Version: 2026-07-28 as an HTTP header and the same value inside params._meta["io.modelcontextprotocol/protocolVersion"]. clientInfo and clientCapabilities ride along on every request too.
  • No session IDs. The inspector never sends an mcp-session-id. If your server returns one, the inspector discards it and surfaces a warning — your server isn’t conforming to the stateless RC.
  • Cancellation is closing the stream. For SSE responses, the inspector closes the response stream to cancel; your server should treat that as a cancel signal.

​
What the inspector tells you

  • If your server doesn’t speak 2026-07-28, server/discover returns -32004 UnsupportedProtocolVersionError and the connection fails with the supported-versions list visible in the Activity log.
  • If your server is missing a capability the inspector needs for a request, you’ll get -32003 MissingRequiredClientCapability back from your server — surface those in the Activity log to confirm they reach you.
  • The Activity log (server card → Activity) is the source of truth — every request and response, success or error, lands there so you can verify headers and _meta content.

​
Not yet supported in the RC client

The 2026 RC client is a preview. A handful of pieces from the SEP family aren’t wired up yet — if you try them, the inspector throws a labeled error instead of silently no-op’ing:
  • subscriptions/listen (long-lived notification stream)
  • Server-initiated requests via MRTR / InputRequiredResult for sampling and listRoots embedded in responses (elicitation via input_required is supported — see Multi-round input)
  • Resumption tokens
  • Automatic detection (HTTP and stdio) falls back to the legacy initialize handshake. An explicit 2026 pin remains exact and does not fall back.
For everything else — tools/list, tools/call, resources/*, prompts/*, OAuth refresh, custom headers, progress notifications — the RC client behaves like the legacy one.
  1. Build a Client called something like Latest protocol sandbox with MCP Protocol → Latest as the host default.
  2. Attach the HTTP server you’re upgrading.
  3. Connect — confirm the server card shows the server info populated from server/discover (name, version, capabilities, instructions).
  4. Run a tools/list and a tools/call from the Tools tab.
  5. Watch the Activity log for the request _meta and the MCP-Protocol-Version header.
  6. Try an unsupported version on a second test server to confirm your -32004 error envelope looks right.
  7. Once your server is happy on Latest, keep one Client on Automatic (or pinned to November (2025-11-25)) so you can flip between versions without rewriting settings.
If you need to talk to a mix of servers on different versions in the same Client, use per-server overrides — the RC server stays pinned to 2026-07-28, the rest fall back to the host default. Background on the 2026-07-28 RC and the stateless direction the protocol is moving in: