Skip to main content
The inspector can speak more than one version of the MCP protocol. By default it negotiates whatever the SDK considers current, but you can pin a different version when you want to test how your server behaves against a specific draft — including the new 2026-07-28 stateless RC. This page covers how to pick a version. Automatic per-server version detection is on the roadmap; for now you tell the inspector which version to use.
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 stable 2025-11-25 server alongside one you’re upgrading to the 2026 RC.

​
Available versions

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 Latest (2025-11-25) and 2026 RC (2026-07-28) 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 Latest or 2026 RC (2026-07-28).
  5. Save.
Every server attached to this Client now connects with that version unless it has its own per-server override.

​
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 (2025-11-25), or 2026 RC (2026-07-28) 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 (2025-11-25), or 2026 RC (2026-07-28).
  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.

​
What changes when you pick the 2026 RC

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 (sampling, elicitation, listRoots embedded in responses)
  • Resumption tokens
  • Backward-compat probes against pre-RC servers — if you point the RC client at an initialize-only server it will fail at server/discover, 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 2026 RC sandbox with MCP Protocol → 2026 RC 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 the RC, keep one Client on Latest 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 Latest. Background on the 2026-07-28 RC and the stateless direction the protocol is moving in: