docs: align the safe-integer justification in streamable-http with tools.mdx - #3289
Merged
localden merged 1 commit intoAug 23, 2026
Conversation
The x-mcp-header integer bound is justified as "the safe range for JavaScript" here and as the IEEE754 double-precision range in server/tools.mdx. Same constraint, same numeric range, two different justifications. The IEEE754 phrasing was agreed in the review of modelcontextprotocol#2772; the revision landed in tools.mdx but not here. No normative change: the bound is untouched.
localden
approved these changes
Aug 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
draft/basic/transports/streamable-http.mdxstill describes thex-mcp-headerinteger bound as "the safe range for JavaScript", whiledraft/server/tools.mdxdescribes the same bound as "the safe range for integers represented using IEEE754 double-precision floating point numbers". Same constraint, same numeric range, two different justifications in one normative document.The IEEE754 phrasing is the one already settled. In the review of #2772, @pja-ant pushed back on the JavaScript framing — "Even in languages that have native integers, sometimes JSON parsing libraries will parse to
doubleby default" — and @mikekistler replied "Fair point. I will revise." That revision landed intools.mdxbut not instreamable-http.mdx. This completes it.Not a normative change. The bound
(−2^53+1 to 2^53−1)is untouched; only the justifying clause changes. Onlydraftis edited — the released2026-07-28copy is deliberately left frozen.I noticed this via the "Aside" section of modelcontextprotocol/conformance#445, which flagged it as "probably a one-line upstream fix". I am not taking on the check described in the body of that issue — as its author notes, the normative question there needs settling first, since asserting either behaviour makes one SDK fail.
Why this matters to me: the divergence I care about is the one downstream of this wording. The C# SDK throws on an out-of-range integer; the TypeScript SDK drops the header silently and lets the call proceed. Precise, consistently-stated normative text is what keeps two SDKs from reading one MUST two ways — and silent omission is the failure mode I find hardest to catch in my own systems, because nothing downstream reports anything wrong.
AI disclosure: This was found and drafted with Claude Code — it located the inconsistency, traced it to the #2772 discussion, and wrote this description. I directed that work and had the change and its rationale explained to me before submitting; it is a one-clause wording swap that I understand and can defend. Per AI_POLICY.md, stating the extent rather than just the fact.