An API gateway in front of a Streamable HTTP MCP server must record which method and which tool each request targets, without parsing JSON request bodies. What does the transport provide for this?
Select an answer to reveal the explanation.
Short Explanation
The transport writes the destination on the outside of the envelope for exactly this reason. Mcp-Method says what kind of call it is, and Mcp-Name says which tool, resource or prompt. Your gateway reads the label and never has to open the letter.
Full Explanation
The Streamable HTTP transport mirrors selected JSON-RPC body fields into HTTP headers so that intermediaries such as load balancers, gateways and observability tooling can route and inspect requests without parsing the body. Mcp-Method carries the method and is required on all requests, and Mcp-Name carries params.name or params.uri and is required for tools/call, resources/read and prompts/get. Values that are not safe ASCII use a Base64 sentinel encoding, and any server that processes the body MUST reject a header and body mismatch with HTTP 400 and HeaderMismatch error -32020, which keeps the header trustworthy. Mcp-Session-Id belonged to protocol versions 2025-03-26 through 2025-11-25; revision 2026-07-28 has no protocol sessions, and modern servers ignore that header and never mint one. MCP-Protocol-Version carries only the protocol version, which must match the version in _meta. Nothing in the transport puts the method or tool name in the query string; every message is a POST to the single MCP endpoint with a JSON-RPC body. Exam caveat: intermediaries enforcing policy on mirrored headers should check the protocol version requires header validation before trusting them. Operational check: capture a tools/call at the gateway and confirm Mcp-Method and Mcp-Name match the body's method and tool name.