Server hangs indefinitely when JSON-RPC request ID exceeds

[manthanghasadiya]

Describe the bug
MCP server becomes completely unresponsive when receiving a JSON-RPC request with an id value exceeding Number.MAX_SAFE_INTEGER (9007199254740991). The server doesn't crash or return an error - it simply stops responding to all requests permanently.

To Reproduce

1. Start any MCP server using the TypeScript SDK
2. Initialize the connection normally
3. Send a request with id: 9007199254740992 (MAX_SAFE_INTEGER + 1)
4. Server hangs indefinitely - no response, no error

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

Expected behavior
Server should either:

• Return a JSON-RPC error response for invalid ID
• Reject the request and continue processing other requests

Actual behavior
Server enters permanent deadlock. Process stays alive (low CPU, ~55MB memory) but responds to nothing. Requires manual restart.

Logs
No error output - server silently hangs.

Process alive: Yes
CPU: 0.25%
Memory: 54MB
Response: None (waited 10+ minutes)

Additional context

• Tested on @modelcontextprotocol/sdk latest version
• Reproducible 100% of the time
• Single malformed request is enough to freeze the server
• IDs at or below MAX_SAFE_INTEGER work fine

[kedarvartak]

hi, can i pick this up? @manthanghasadiya

[felixweinberger]

Numeric IDs above Number.MAX_SAFE_INTEGER lose precision at JSON.parse before the SDK sees them, so this isn't really fixable SDK-side without swapping the JSON parser. For IDs in this range the spec already supports string IDs (RequestId = string | number).

Are you seeing this with a real client/server in practice, or is this an edge case you found through testing? If there's a real-world client hitting this we'd want to understand why it's using numeric IDs this large.

[manthanghasadiya]

@felixweinberger This came up during fuzzing with mcpsec - not a real client/server scenario.

I was testing edge cases around ID handling and found the precision loss. Happy to close this, if that's the call. Just wanted to flag it in case it wasn't already documented.