MCP-SCH-004
x-mcp-header only on string/integer/boolean — never number
“MUST only be applied to parameters with primitive types (integer, string, boolean). Parameters with type number are not permitted.” — spec anchor
How to fix this
Apply `x-mcp-header` only to parameters typed `string`, `integer` or `boolean`. `number` is explicitly not permitted, because it has no unambiguous header representation.
How the validator checks this
Probe P2.1, against a streamable-http server on the modern protocol. What it reports:
- pass
- x-mcp-header used only on string/integer/boolean properties
- fail
- x-mcp-header is only permitted on string, integer or boolean — got ${badType.map((d) =>
Quoted from the probe that runs this check, so it cannot drift from what the validator actually reports.
This rule is checked deterministically: a fail here is a certain violation, not an inference.
Checked in the same request as MCP-HDR-008, MCP-HDR-009, MCP-RES-003, MCP-RES-006, MCP-RES-007, MCP-ERR-003, MCP-ERR-004, MCP-ERR-005, MCP-ERR-008, MCP-CAC-001, MCP-CAC-002, MCP-CAC-003, MCP-CAC-004, MCP-CAC-005, MCP-SCH-001, MCP-SCH-002, MCP-SCH-003, MCP-SCH-005, MCP-SCH-006, MCP-SCH-007, MCP-SEC-004, MCP-SEC-005, MCP-SEC-006, MCP-DEP-005.
Check your own server against this rule
The validator makes real protocol requests and reports this rule as pass, warn or fail alongside the other 78. Validate a server or read how the check works.
Other Tool/prompt schema and x-mcp-header rules
- MCP-SCH-001x-mcp-header is non-empty and matches RFC 9110 token syntax
- MCP-SCH-002x-mcp-header contains no control characters, CR, or LF
- MCP-SCH-003x-mcp-header values are case-insensitively unique per inputSchema
- MCP-SCH-005x-mcp-header property is statically reachable via properties only
- MCP-SCH-006inputSchema/outputSchema validate against the declared or default 2020-12 dialect
- MCP-SCH-007Tool, prompt, and resource names are header-safe ASCII