A Streamable HTTP server receives a POST whose Mcp-Method header says tools/list while the JSON-RPC body says tools/call. The specification requires the server to reject it. What risk does that rule prevent?
Select an answer to reveal the explanation.
Short Explanation
Imagine you're shipping a box whose label says "books" but the box holds fireworks. The sorting depot routes on the label and the recipient opens the box, and nobody sees the same thing. That's why a header that doesn't match the body gets rejected outright.
Full Explanation
Streamable HTTP requests carry routing headers such as MCP-Protocol-Version, Mcp-Method, and Mcp-Name for tools/call, resources/read and prompts/get, so that intermediaries like load balancers, gateways and observability tools can route and inspect traffic without parsing the body. The specification requires servers that process the body to reject any request whose header values do not match the corresponding body values, explaining that this prevents vulnerabilities when different components rely on different sources of truth, for example a load balancer routing on the header while the server executes the body. A gateway policy that allows tools/list but blocks a sensitive tools/call could otherwise be bypassed. The rejection is HTTP 400 with the HeaderMismatch error, -32020, which also applies when required headers are missing or malformed. The TLS claim fails because headers and body travel in the same protected connection; a mismatch says nothing about TLS. The bandwidth claim fails by concept: the rule is a security control against inconsistent interpretation, not an efficiency measure. Treating the header as authoritative and rewriting the body fails because the specification requires rejection, not reconciliation. Exam caveat: integer values should be compared numerically, so 42 and 42.0 match. Operational check: send a POST with a mismatched Mcp-Method and confirm a 400 response carrying -32020.