A client sends a tools/call request with an id of null, and the MCP server rejects it. A developer points out that base JSON-RPC 2.0 tolerates a null id. Why is the rejection consistent with MCP?
Select an answer to reveal the explanation.
Short Explanation
MCP tightens one JSON-RPC rule: your request id can be a string or a number, but never null. Think of it as a claim ticket — a blank one can't be matched to anything. And you can't hand out the same ticket twice while it's still open.
Full Explanation
The MCP base protocol states that requests MUST include a string or integer ID and that, unlike base JSON-RPC, the ID MUST NOT be null. It also requires that a request ID not match the ID of any other request the sender has issued and not yet received a response for. Responses repeat the request's ID, so a null value would make correlation ambiguous, particularly when many requests are in flight on one connection or stream. The server is therefore right to reject the request. Requiring UUID strings is not part of the rule; any string or integer is acceptable, and uniqueness is only required among the sender's outstanding requests. Requiring sequential integers starting at 1 per connection invents a constraint, and connection-scoped numbering would also clash with the stateless design of this revision. Repeating the method name in the ID confuses two unrelated members; routing uses the method member, and the ID only correlates requests with responses. Exam caveat: the multi round-trip pattern requires the retried request to use a new ID, which follows from the same uniqueness rule. Operational check: inspect the client's ID generator to confirm it never emits null and never reuses an ID until the matching response or error arrives.