http-custom-headers scenario puts x-mcp-header on `type:"number"` params (forbidden by SEP-2243)

[halter73]

Summary

The client scenario http-custom-headers (src/scenarios/client/http-custom-headers.ts) declares two tool parameters with an x-mcp-header annotation on a JSON Schema type: "number" property, and then asserts the client mirrors them into Mcp-Param-* headers:

priority:  { type: 'number', /* ... */ 'x-mcp-header': 'Priority' },   // ~line 296
float_val: { type: 'number', /* ... */ 'x-mcp-header': 'FloatVal' },   // ~line 322
// ...
this.checkParamHeader(req, 'Priority', args.priority, 'number');       // ~line 453
this.checkParamHeader(req, 'FloatVal', args.float_val, 'number');      // ~line 480

This violates SEP-2243, which the draft spec now states unambiguously (clarified in modelcontextprotocol/modelcontextprotocol#2863):

The x-mcp-header extension ... MUST only be applied to parameters with primitive types (integer, string, boolean). Parameters with type number are not permitted.
— docs/specification/draft/server/tools.mdx

Why this matters

A spec-conformant client must reject (exclude) tools whose x-mcp-header annotations are invalid — this is exactly what the sibling scenario http-invalid-tool-headers verifies (it includes an "x-mcp-header on a primitive-only constraint" negative case). Because test_custom_headers carries x-mcp-header on type:"number" params, a conformant client excludes the whole tool from its listing, so the subsequent tools/call sends no Mcp-Param-* headers. Every positive "client mirrors Mcp-Param-X" check then fails, while the negative checks pass. The scenario therefore cannot be passed by a spec-conformant client.

This affects main and the latest published @modelcontextprotocol/conformance@0.2.0-alpha.4.

Suggested fix

• Change priority and float_val to type: "integer" (the priority value is already integer-valued, and the check comment even says "integer number"), or drop the x-mcp-header annotation from the number-typed param, so the positive scenario only exercises spec-permitted primitive types (integer/string/boolean).
• Optionally add a type:"number" row to http-invalid-tool-headers asserting clients reject x-mcp-header on number, and refresh any sep-2243.yaml text that still implies number is allowed.

Context

Filed from the C# SDK side while validating SEP-2243 conformance for modelcontextprotocol/csharp-sdk#1610. The C# client already emits Mcp-Param-* headers correctly for permitted primitive types and intentionally rejects x-mcp-header on number per the spec, so this one scenario stays red purely because of the harness declaration. Tracked on our side in modelcontextprotocol/csharp-sdk#1655.