Tasks requests over Streamable HTTP omit the required Mcp-Name header (SEP-2663)

[jwcarman]

Summary

When driving the io.modelcontextprotocol/tasks extension (protocol 2026-07-28),
Inspector sends tasks/get / tasks/update / tasks/cancel without the Mcp-Name
header. SEP-2663's Streamable HTTP binding makes that header a client MUST for
these methods, so a conforming server rejects every task poll with a JSON-RPC
-32020 (HeaderMismatch) and HTTP 400 — task-based tools are unusable from
Inspector against strict servers.

Spec citation (SEP-2663, Streamable HTTP transport binding)

When tasks/get, tasks/update, or tasks/cancel is sent over the Streamable
HTTP transport, the client MUST set the Mcp-Name header to the value of
params.taskId. This allows transport intermediaries and load balancers to route
subsequent requests for the same task to the server instance holding its state,
which is typically required for correctness. The Mcp-Method header is set to
the JSON-RPC method name per standard header conventions.

Note the MUST is unconditional: even against servers that keep task state in a
shared store (and don't need routing affinity for correctness), the client is
required to send the header so intermediaries can route for the servers that do.

Reproduction

1. Start any 2026-07-28 server that validates transport routing headers and
   exposes a task-augmented tool (observed against mocapi's
   tasks example, which validates headers before dispatch per the transport prose).
2. In Inspector, call the task tool (the tools/call itself succeeds — Inspector
   correctly sends Mcp-Method and Mcp-Name: <tool name> there).
3. Inspector's follow-up tasks/get poll fails.

Actual — request is sent with Mcp-Method: tasks/get but no Mcp-Name;
server responds HTTP 400:

{"jsonrpc":"2.0","error":{"code":-32020,"message":"HeaderMismatch: missing required header Mcp-Name for method tasks/get"},"id":1}

Expected — per the SEP, the request carries:

Mcp-Method: tasks/get
Mcp-Name: <params.taskId>

and the poll succeeds.

Fix

Wherever Inspector builds Streamable HTTP requests for the tasks extension, set
Mcp-Name to params.taskId for all three methods (tasks/get, tasks/update,
tasks/cancel) — mirroring the existing behavior for tools/call (params.name),
prompts/get (params.name), and resources/read (params.uri).

(Possibly related to the header work tracked in #1628, which is closed.)

Environment

• Inspector: 2.0.0
• Protocol: 2026-07-28, tasks extension (SEP-2663)
• Server: mocapi 1.3.0-SNAPSHOT (Streamable HTTP, header validation per transport prose)

[jwcarman]

Concrete capture from Inspector 2.0.0's own transport log (tasks/get against a conforming server, HTTP 400 returned):

Request headers sent:

accept: application/json, text/event-stream
content-type: application/json
mcp-method: tasks/get
mcp-protocol-version: 2026-07-28

No Mcp-Name header — while the body carries the value it should have been set to:

{
  "jsonrpc": "2.0",
  "id": "inspector-ext-1",
  "method": "tasks/get",
  "params": {
    "taskId": "J2tseZbBR3j0xESA7XNU-lcCMCrE3BYQ1B697YGvPDw",
    "_meta": { "...": "..." }
  }
}

So the fix is exactly the one-liner from the report: when building the transport request for tasks/get / tasks/update / tasks/cancel, set Mcp-Name to params.taskId alongside the Mcp-Method header that is already being set correctly.

[jwcarman]

Root-caused: the header derivation lives in the SDK, not Inspector — StreamableHTTPClientTransport._applyBodyDerivedHeaders only knew params.name/params.uri sources, so tasks/* fell through with no Mcp-Name. Fix submitted upstream: modelcontextprotocol/typescript-sdk#2613 (adds the SEP-2663 tasks/* → params.taskId rows to the shared MCP_NAME_HEADER_SOURCE table, driving both client emission and server-side validation). Once that releases, Inspector needs only the @modelcontextprotocol/client dependency bump.