> ## Documentation Index
> Fetch the complete documentation index at: https://mcpjam-mintlify-docs-update-pr-3829-1786337254828.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# MCP protocol versions
> Pin the inspector to a specific MCP protocol version — including the 2026-07-28 stateless RC — to test how your server behaves across versions.
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
| Option | Stored pin | Transport | Use it when |
| ------------------------------------ | ------------ | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Automatic** | none | HTTP + stdio: `server/discover`, then legacy fallback | Detect 2026 support from the server; otherwise use the version negotiated by `initialize`. This is the default. |
| **Latest (2026-07-28)** | `2026-07-28` | HTTP in MCPJam's preview (Streamable HTTP POST) | You want to test your server against the newest stateless revision — no `initialize` handshake, `server/discover` for capabilities, per-request `_meta`. |
| **November (2025-11-25)** | `2025-11-25` | HTTP, STDIO, SSE | Pin to the November stateful release. The initialize handshake offers only this version. |
| **2025-06-18** | `2025-06-18` | HTTP, STDIO, SSE | Test against the June 2025 stable revision. |
| **2025-03-26** | `2025-03-26` | HTTP, STDIO, SSE | Test against the March 2025 stable revision. |
| **Host default** *(per-server only)* | — | — | Inherit whatever the Client's MCP Protocol tab is set to. |
**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
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](#multi-round-input-mcp-2026-07-28-input_required))
* 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.
## Recommended testing flow
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.
## Recommended reading
Background on the 2026-07-28 RC and the stateless direction the protocol is moving in:
* [MCP Is Growing Up](https://aaif.io/blog/mcp-is-growing-up/) — AAIF's overview of what the 2026-07-28 RC means for teams building agentic systems.
* [2026-07-28 release candidate announcement](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) — the official blog post walking through what the RC changes and why.
* [MCP specification (draft)](https://modelcontextprotocol.io/specification/draft) — the in-progress spec text the inspector's RC client targets.