Unsupported MCP protocol version: the 400 from Sume's server

Sume's hosted MCP endpoint, https://mcp.sume.com/mcp, answers an authenticated request whose MCP-Protocol-Version header names a version it does not support with HTTP 400 and a JSON-RPC error -32600, message "Unsupported MCP protocol version." A client built for the 2026-07-28 revision is meant to treat that as a legacy server and fall back to the initialize handshake.

The server behavior comes from the hosted MCP code as read on 2026-09-29. The client rules come from the MCP project's Streamable HTTP and Versioning pages. Sume's own connect steps are in the MCP quickstart.

Which versions does the endpoint accept?

Current code lists three protocol versions and defaults to the newest of them. The 2026-07-28 revision is not on the list.

Why does a new client see a 400 at all?

The 2026-07-28 revision drops the initialize handshake. Every request carries its version, and the Streamable HTTP page says the client sends it in the MCP-Protocol-Version header, for example MCP-Protocol-Version: 2026-07-28. A server that does not support that version must answer 400 with an UnsupportedProtocolVersionError. The spec's changelog numbers that error -32022.

Sume's 400 carries -32600 instead. That difference matters for the next step.

What should the client do next?

The Streamable HTTP page tells a client that supports both eras to try a modern request first and, on a 400, inspect the body. A recognized modern JSON-RPC error means a modern server: retry with a version it lists. If the body is empty or is not a recognized modern error, fall back to initialize and continue on the legacy version.

Read against that rule, Sume's -32600 body is not the modern error, so a spec-following client falls back to initialize. The endpoint's initialize then answers with the requested version if it is supported, and with 2025-11-25 otherwise. This post did not test each client, so check that yours completes the fallback.

curl -s https://mcp.sume.com/mcp \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"probe","version":"0"}}}'

What else changes on the wire?

A GET to the endpoint answers 405 with "Remote MCP uses POST JSON-RPC requests.". Batches: current code allows 1 to 4 messages in one request only on 2025-03-26, and requires one message per request on later versions.

Browser-origin requests are checked before the version: a disallowed Origin gets 403 with the code forbidden_origin, so a 403 is an origin problem, not a version one. A 400 with -32600 and the text above is the version signal to look for. Log the response body when a new client fails to connect, because the status alone does not tell these cases apart.

None of this touches what the tools do. The tool list, the OAuth scopes and the job model are the same whichever version a client negotiates.