A Streamable HTTP client fetches tools/list and finds that one tool's inputSchema places x-mcp-header on a parameter of type number. The server's other nine tools are well formed. What should the client do?
Select an answer to reveal the explanation.
Short Explanation
One mislabeled jar doesn't mean you throw out the whole pantry. You set that one tool aside, note why, and keep cooking with the rest. The trap is Base64 — it fixes awkward characters, not a forbidden parameter type.
Full Explanation
The x-mcp-header constraints say the annotation must only be applied to parameters of primitive types integer, string or boolean, and parameters of type number are not permitted. Clients using Streamable HTTP must reject tool definitions where any x-mcp-header value violates these constraints, and rejection means excluding the invalid tool from the result of tools/list. Clients should log a warning that includes the tool name and the reason, and the specification explains the intent: a single malformed definition should not prevent the other valid tools from being used. Rejecting the whole list punishes nine valid tools for one defect and is not what the rules require. Base64 encoding exists to carry string values that are not header-safe, such as non-ASCII text or leading spaces; it does not make a forbidden type acceptable, and the definition itself remains invalid. Keeping the tool and dropping the header is wrong because clients must honor valid x-mcp-header annotations and must reject invalid ones; they are not optional hints like tool annotations. Exam caveat: clients on stdio may ignore x-mcp-header entirely, so the same tool might still appear for a stdio connection. Operational check: confirm the client's tool list shows nine tools and its log contains a warning naming the excluded tool and the number-type violation.