A gateway rate-limits tenants using a tenant value that clients mirror into an Mcp-Param header. Some requests arrive with an older MCP-Protocol-Version value, or with none at all. What should the gateway do with those requests?
Select an answer to reveal the explanation.
Short Explanation
A mirrored header is only as honest as the check behind it. Older protocol versions never required servers to compare headers with the body, so a client could write any tenant it likes. When the version doesn't guarantee that check, you turn the request away instead of trusting the label.
Full Explanation
The Streamable HTTP transport requires servers that process the body to reject requests whose mirrored header values do not match the body, returning HTTP 400 with HeaderMismatch error -32020. This prevents a gap in which one component, such as a load balancer, acts on the header while the server executes on the body. The transport adds a note for intermediaries that enforce policy based on mirrored headers, such as routing or rate-limiting by tenant: they SHOULD verify that MCP-Protocol-Version indicates a version requiring header and body validation, and if the version is older or the header absent, they SHOULD reject the request rather than trust unvalidated header values. Trusting the header because servers validate it holds only for versions that require validation, which is exactly what is in doubt here. clientInfo is a SHOULD-level, self-reported field, not a required one, and it is not to be relied on for security decisions such as tenant enforcement. Forwarding without limits gives an attacker an easy bypass, since faking an old version would switch rate limiting off. Exam caveat: Mcp-Param headers come from tool parameters annotated with x-mcp-header, so a tenant value must not be sensitive. Operational check: send requests with a forged tenant header and an old or missing protocol version through the gateway and confirm they are rejected.