MCP protocol version mismatch: HTTP 400 on initialize

A remote MCP server can refuse the protocol version your client asks for. In our tests Qt Documentation MCP answered our initialize request for protocol 2025-06-18 with HTTP 400 and an empty body. By contrast, 20 other servers we list asked for the same version answered with an older one and the handshake went on (16 answered 2024-11-05; 4 answered 2025-03-26).

Short answer

HTTP 400 on the very first request to a remote MCP server can mean it does not accept your client's protocol version. Update the client or its MCP SDK, or pick another version if your client lets you: Qt Documentation MCP answered for 2025-03-26 and 2025-11-25 in our retest.

Last tested 2026-11-11

How we test: methodology. Context cost: lowest context cost MCP servers. Not tested by us: security, output quality, and behaviour with real credentials.

Symptom

Adding a remote (Streamable HTTP) MCP server fails at once. The client's log shows the first POST, the initialize request, coming back with 400 Bad Request, sometimes with no response body, so there is no JSON-RPC error message to read.

The exact error we saw

Server	What it printed (verbatim)	Where we saw it	Tested
Qt Documentation MCP (official, remote) `https://qt-docs-mcp.qt.io/mcp`	`HTTP 400:`	our remote probe, initialize with protocolVersion 2025-06-18 (empty response body)	2026-11-11
Qt Documentation MCP (official, remote) `https://qt-docs-mcp.qt.io/mcp`	`HTTP 400 for protocolVersion 2025-06-18; 200 for 2025-03-26 and 2025-11-25 (qt-docs-server 0.3.0).`	our recorded retest note, same night	2026-11-11

Cause

In initialize the client sends the protocol version it wants. The spec says a server that does not support it must answer with another version it does support, and the client then decides whether to continue (MCP spec, lifecycle). Over HTTP the client also sends an MCP-Protocol-Version header, and a server must answer 400 Bad Request to an invalid or unsupported value there (MCP spec, transports).

Our probe put 2025-06-18 in both places, so we can't tell which one Qt Documentation MCP rejected. In our retest the same night it answered with HTTP 200 for 2025-03-26 and 2025-11-25.

Fix

Find the version your client sends. Look for the initialize request and its protocolVersion in your client's MCP log. not tested by us
Update the client or its MCP SDK so it offers a version the server accepts. If the client lets you choose a version, try another one. Qt Documentation MCP accepted 2025-03-26 and 2025-11-25 in our retest. not tested by us
If you run the server: answer initialize with a version you support instead of an HTTP error, as the lifecycle section says, so clients can negotiate. not tested by us

What negotiation looks like when it works

Our test client asks every server for 2025-06-18. These 20 servers we list answered with an older version, and the handshake went on, which is what the spec describes. The version each one answered is taken from our recorded initialize response.

Answered 2024-11-05 (16): AWS KB Retrieval (legacy reference), BLA (Blind LLM Agents), Brain4Agent, Browser Use, GitHub (legacy reference), Hugging Face Spaces, Kensaku MCP, Knowledge Graph (itseasy21), Knowledge Graph memory, Moodle-MCP, Playwright (Automata Labs), Postgres (legacy reference), Puppeteer (legacy reference), Puppeteer MCP (community), Scryfall MCP, YouTube Transcript

Answered 2025-03-26 (4): AWS Knowledge MCP (official, remote), GitMCP (official, remote), n8n-MCP, Snyk CLI MCP (official)

Affected listings

Qt Documentation MCP (official, remote) (qt-docs-remote, tested 2026-11-11, status working)

This is the HTTP 400 we recorded for protocol 2025-06-18. A retest the same night answered for 2025-03-26 and 2025-11-25.

More troubleshooting: all troubleshooting pages · MCP error -32000: Connection closed · MCP servers that need an API key or sign-in. Quotes are verbatim from our own test logs (colour codes removed; a trailing … marks a shortened line). We have not run these servers inside Claude Code, Claude Desktop or Cursor.

FAQ

What does HTTP 400 on MCP initialize mean?

The server refused the very first request. In our tests that happened when a remote server did not accept the protocol version we asked for (2025-06-18). It answered HTTP 400 with an empty body instead of naming a version it supports.

Is a server allowed to reject a protocol version?

The MCP spec says that in initialize, a server that does not support the requested version must answer with another version it supports, and the client decides whether to continue. A 400 is specified for an invalid or unsupported MCP-Protocol-Version header on HTTP requests.

Which protocol versions did servers answer with in your tests?

We asked for 2025-06-18. Of the servers we list, 20 answered with an older version and continued (16 answered 2024-11-05; 4 answered 2025-03-26). <a href='/tools/qt-documentation-mcp-remote/'>Qt Documentation MCP</a> answered HTTP 400 instead.