coerce_request_id() folds non-canonical numeric strings, conflating wire-distinct JSON-RPC ids

Inizia in src/mcp/shared/dispatcher.py, in coerce_request_id(), e leggi il test esistente per il comportamento previsto di convertire "7" in 7. Aggiungi una copertura di regressione per le stringhe numeriche non canoniche e verifica che wire ids distinti rimangano distinti tra le risposte in sospeso, la cancellazione e il routing dei progress-token.

Initial Checks

• I confirm that I'm using the newest release of my line (the latest 2.x, or the latest 1.x if I'm still on v1)
• I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue

Release line

2.x (current stable)

Description

On current main, coerce_request_id() in src/mcp/shared/dispatcher.py folds a stringified id to int with a bare int(request_id). That accepts a lot more than a canonical integer string, so ids that are distinct on the JSON-RPC wire collapse onto one correlation key:

coerce_request_id('007')   -> 7
coerce_request_id('+7')    -> 7
coerce_request_id('1_000') -> 1000
coerce_request_id(' 7 ')   -> 7
coerce_request_id('٧')     -> 7

This shared key backs _pending (response correlation), _in_flight (cancellation), and progress-token routing. So a peer, or a caller using CallOptions["request_id"], that uses e.g. 10 and "1_0" as two ids has them merged. A notifications/cancelled for one hits the other, and the first can't be cancelled. It's the same cross-wiring class as #3060, but between ids that are genuinely different on the wire.

JSON-RPC 2.0 treats String and Number ids as distinct value types, and the function's own intent (and its test, "7" -> 7) is the canonical "peer stringified an int" case. The forms above aren't that. They're an artifact of Python's int(). The docstring says "matches the TS SDK", but JS Number("1_000") is NaN and Number("0x10") is 16, so today's behavior matches neither.

The narrow fix is to fold only when the string equals str(int(s)), which keeps the intended "7" -> 7 and "-3" -> -3 behavior and leaves every other string a distinct id. I have a patch and a regression test for it (both dispatchers share the function) and I'm happy to open a PR once this is triaged and assigned.

Disclosure: I used an AI coding assistant to help explore the code and draft this. I verified the reproduction and understand the fix myself.

Example Code

from mcp.shared.dispatcher import coerce_request_id

for raw in ("007", "+7", "1_000", " 7 ", "٧"):
    print(repr(raw), "->", repr(coerce_request_id(raw)))
# every line prints an int, so all five distinct wire ids share one key

Python & MCP Python SDK

Python 3.11.14, python-sdk main @ 5bc9e07, macOS