fix(core): validate RequestId integers against Number.MAX_SAFE_INTEGER

[lanxevo3]

Per JSON-RPC spec and JavaScript Map semantics, integer request IDs must be safe integers. When a request id exceeds Number.MAX_SAFE_INTEGER, JavaScript Map lookups silently lose precision, causing the server to never find the matching response and hang permanently.

Bug

Send any JSON-RPC request with id: 9007199254740992 (MAX_SAFE_INTEGER + 1):

{"jsonrpc":"2.0","id":9007199254740992,"method":"tools/list"}

Before: Server becomes permanently unresponsive — no crash, no error, requires manual restart.
After: Returns JSON-RPC InvalidRequest error immediately, server stays responsive.

Root Cause

RequestIdSchema = z.union([z.string(), z.number().int()]) accepts any integer. When such an ID is used as a JavaScript Map key (in _requestResponseMap and _requestToStreamMapping), precision is lost:

const m = new Map();
m.set(9007199254740992, "value");
m.get(9007199254740992); // → undefined (precision lost!)

The server waits indefinitely for a response it can never route.

Fix

Added .refine() to RequestIdSchema to validate integer IDs against Number.MAX_SAFE_INTEGER:

z.number().int().refine((n) => Math.abs(n) <= Number.MAX_SAFE_INTEGER, {
  message: `Request ID must be a safe integer (|id| ≤ ${Number.MAX_SAFE_INTEGER})`
})

The JSON-RPC error response is returned at parse time — the server remains fully functional.

Fixes #1765.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 735b634

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1806

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1806

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1806

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1806

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1806

commit: 735b634

[felixweinberger]

Closing per #1765. The reporter confirmed this was a fuzzing find, not a real-world scenario. Precision loss for numeric IDs above MAX_SAFE_INTEGER happens at JSON.parse before the SDK sees the value. Clients needing IDs in that range should use string IDs, which the spec already supports.