Repository navigation
Forward Mcp-Name header in the McpTransportContext for extension validation #1317
Description
Tasks may want to validate HTTP headers. For example, SEP-2663 Tasks mandates, in Streamable HTTP routing headers:
When tasks/get, tasks/update, or tasks/cancel is sent over the Streamable HTTP transport, the client MUST set the Mcp-Name header (defined by SEP-2243) to the value of params.taskId
In that case, the taskId is in the request params, which would likely be interpreted at the Feature level, similar to x-mcp-header in #1199.
Passing headers to features can be accomplished with a context extractor at the transport-level, but that defeats the server / transport separation. Mcp-Method is validated in the transport already for every method, so we do not need to pass it down, but we should extract, decode and pass the Mcp-Name header if present.
Activity
media-ctrl commentedon Nov 8, 2026
The routing role and the validation role pull in different directions here, and pinning that down is the part worth settling in the SEP.
Mcp-Methodcan be validated in the transport for every method because the transport knows the method name before a body exists.Mcp-Namecannot work the same way: its legality is a function of the task id inside the request params, which only exists after the body is decoded. So one header has two moments.Putting the raw value on
McpTransportContextserves (1) and leaves (2) to theFeature, which is the right split, but only if the context carries the header verbatim and the feature is documented as owning the equality check. If the transport normalised or dropped a mismatched value on the way through, a client bug would surface as a server routing bug and that is a long debug.Two smaller things from the server side of this. Header names are case-insensitive, so read the context key case-insensitively or populate the fast lookup with a folded key. And the header can legally arrive more than once through a proxy, so treat a repeated or comma-joined value as invalid rather than taking the first one, otherwise a misconfigured proxy becomes a wrong-task read.
On the transport extractor tradeoff you raised: extracting in the transport and passing a typed value down does not have to break the server/transport separation, as long as the context type is transport-agnostic. The separation argument bites when the feature has to reach back into the transport for the raw header, not when the transport hands it a decoded value it already had.
neerajbhatt commentedon Nov 8, 2026
Hi @Kehrlann , I’ll start working on #1317. I previously contributed to the servlet header handling in #982. I’ll look at how the modern server HTTP transport handles Mcp-Name, add the context propagation and focused tests, and link the PR here when it’s ready.
Kehrlann commentedon Nov 9, 2026
Hey @neerajbhatt please go ahead.