mcp: header-only 2026 request against unsupported server returns -32602 instead of -32022 #1346

What I did

Configured a server with ServerOptions.SupportedProtocolVersions = []string{"2025-11-25"}.
Sent a tools/list request with only the Mcp-Protocol-Version header (no _meta in body):

POST /mcp
Content-Type: application/json
Accept: application/json, text/event-stream
Mcp-Protocol-Version: 2026-07-28

{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}

Reproduced with tools/list, tools/call, and server/discover.

What I saw

HTTP 400, error code -32602 (InvalidParams):

{"jsonrpc":"2.0","id":1,"error":{"code":-32602,"message":"missing or invalid _meta field \"io.modelcontextprotocol/protocolVersion\""}}

What I expected

HTTP 400, error code -32022 (UnsupportedProtocolVersion):

{"jsonrpc":"2.0","id":1,"error":{"code":-32022,"message":"...","data":{"supported":["2025-11-25"],"requested":"2026-07-28"}}}

SDK version

v1.8.0 and current main.

Go version

go1.26.2

Why this is a spec violation

The MCP 2026-07-28 streamable HTTP spec states:

"If the server does not implement the requested protocol version (whether the version is unknown to the server, or is a known version the server has chosen not to support), it MUST respond with 400 Bad Request and an UnsupportedProtocolVersionError listing its supported versions."

No exception is made for cases where _meta is also absent. The version check is independent of the _meta check. Returning -32602 instead of -32022 violates this MUST.

The backward-compatibility section of the spec describes clients inspecting the error body to distinguish "unsupported version" (retry with a different version) from "bad request" (fix the request). Returning -32602 breaks this client fallback logic — the client cannot tell if its version is rejected or its request is malformed.

Root cause

In streamable.go, the per-message dispatch loop (around line 1704) enters the SEP-2575 validation branch whenever protocolVersion >= "2026-07-28" (from the Mcp-Protocol-Version header). Inside that branch:

1. headerVersion == "" → false (header is present, so this passes)
2. metaVersion == "" → true → returns -32602 immediately

The version-supported check (-32022) is never reached because metaVersion is empty — the request has no _meta. The supported-list check sits downstream in server.go's handle(), past the _meta validation gate.

Note on #1173

Issue #1173 (now closed) covered a different path: the Mcp-Protocol-Version header with a version sorting below 2026-07-28 returns a plain-text 400 instead of -32022. That path is streamable.go:412. This issue is the complementary case: a header version sorting at or above 2026-07-28, where the version is unsupported, returns -32602 instead of -32022. Different branch, same class of problem.

Proposed fix

In the per-message dispatch block in streamable.go, before checking metaVersion, check whether headerVersion is in the server's supported set. If not, return -32022:

if (jreq.IsCall() && protocolVersion >= protocolVersion20260728) || metaVersion != "" {
    headerVersion := protocolVersionFromContext(req.Context())
    // Check version support before validating _meta presence.
    if headerVersion != "" && !slices.Contains(supportedVersions, headerVersion) {
        data, _ := json.Marshal(UnsupportedProtocolVersionData{
            Supported: supportedVersions,
            Requested: headerVersion,
        })
        writeJSONRPCError(w, http.StatusBadRequest, jreq.ID, &jsonrpc.Error{
            Code:    CodeUnsupportedProtocolVersion,
            Message: fmt.Sprintf("protocol version %q is not supported", headerVersion),
            Data:    data,
        })
        return
    }
    // ... existing metaVersion == "" check follows
}

Happy to open a PR if the approach is confirmed.