What is a common bug that JSON-RPC tracing reveals in MCP server implementations?
The classic MCP tracing find is an `id` mismatch: the server mints a fresh response id instead of echoing the request id, so the client can never correlate it and the call hangs forever.
Picture a busy coat check. You hand over your coat and get ticket number 47. Later you come back with ticket 47, and the attendant matches the number to find your coat. The number is the only link between you and your coat. Now imagine the attendant hands your coat back to someone holding a brand-new ticket they printed themselves, number 999. Your ticket 47 never matches anything, so you stand there waiting forever, even though your coat is sitting right on the rack. JSON-RPC works the same way: the `id` field is the ticket. The client keeps a list of tickets it is waiting on. If the server replies with the wrong ticket number, the client cannot find the matching entry, so it waits, the response is thrown away, and the call looks like it silently hung.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
MCP rides on JSON-RPC 2.0, and almost every confusing failure you hit while building or debugging a server comes back to one field: the id. It is a tiny piece of the message, but it is the only thing that ties a response back to the request that triggered it. When it goes wrong, the failure mode is maddening, because nothing errors. The call just hangs.
This question is really about understanding request and response correlation, and about knowing that tracing is the tool that turns an invisible hang into an obvious one-line diagnosis. An interviewer asking it wants to hear that you know what the id does, what breaks when it is wrong, and how a trace that logs method, id, and latency per call makes the bug jump out.
This deep dive walks through how correlation works, why a mismatch is silent rather than loud, exactly what to log, how to read a trace to tell a dropped call from a slow one, and the subtler traps like notifications and multi-server id collisions.
Why the id field exists
JSON-RPC 2.0 is an asynchronous, multiplexed protocol. A client can have many requests in flight on a single connection at the same time. Responses can come back in any order. So the protocol needs a way to say which response answers which request, and that way is the id field.
Every request carries an id, usually an incrementing integer or a string. The contract is simple and strict: the server must echo that exact id back in the response. The id is the correlation key, and it is the only one. There is no other field that links the two messages.
This is why MCP can fan out concurrent tool calls over one stdio pipe without confusion. The client fires tools/call with id 1, id 2, and id 3, and whichever finishes first comes back tagged with its own id. The client matches each by id, no matter the arrival order.
The id can be an integer or a string, and the spec is strict that the response must carry the same value and type. That subtlety matters more than it looks. A server that helpfully serializes everything to a string, or a client that parses every id to a number, will produce ids that look identical when printed in a log but fail a strict equality check at runtime. The whole correlation machinery rests on that one comparison being exact.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Symptom in trace | Likely cause | What to log |
|---|---|---|
| Request sent, no response line ever | Server crashed, dropped the call, or never replied | Outgoing id plus a timeout marker |
| Response arrives with a different id | Server minted a new id instead of echoing it | Both request and response ids side by side |
| Response arrives slowly but matches | Slow tool, not a correlation bug | Per-call latency from send to receive |
| Reply sent to a message with no id | Server answered a notification it should ignore | Direction plus whether an id was present |
Real products, models, and research that use this idea.
- The official mcp-inspector tool logs every JSON-RPC message with method and id so you can watch correlation live while testing a server.
- Claude Code emits an MCP debug log that records each request id and round-trip latency, surfacing hung calls during a session.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you distinguish a dropped JSON-RPC call from a tool that is merely slow?
Watch whether a response line ever appears for the id. No response at all points to a drop or crash; a late but matching response points to slow tool execution. Per-call latency from send to receive separates the two.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Blaming a hung MCP call on a slow tool or a crashed server when tracing shows the response arrived fine but carried the wrong id, so the client dropped it.
60 second bullets to scan on the way to the call.
What the JSON-RPC id field correlates
How the client pending-request map keys on id
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.