Click any words you think contain an error. Click again to unmark.
The message has no `id`, which marks it a notification, but `tools/call` expects a response, so it needs an `id` for request-response correlation.
Think of ordering at a busy coffee shop. When you want a drink back, the barista writes a number on your cup so they can call it out when ready. That number is the `id`. This message asks the server to read a file and hand back the contents, so it definitely wants something returned. But it forgot to write a number on the cup. In JSON-RPC, a message with no number is a notification, a fire and forget shout where you expect nothing back. The server is allowed to stay silent. So the client waits forever for an answer that, by the rules, will never come. The fix is simple: write a number on the cup, like `"id": 1`.
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.
This question looks like a JSON syntax puzzle, but it is really a protocol-semantics question. The JSON itself is perfectly well formed: balanced braces, valid strings, a recognizable method and params. Nothing a linter would catch. The defect lives one level up, in what JSON-RPC 2.0 says this particular shape means.
MCP is built on JSON-RPC 2.0. Every interaction between a host and a server, from the initialize handshake to listing tools to invoking them, is a JSON-RPC message. So the rules of JSON-RPC are the rules of MCP at the wire level. To debug MCP, you have to read these messages the way the spec reads them.
The trap here is that the message carries a method and params, which makes it feel like an obvious request. But JSON-RPC does not decide request versus notification from the method. It decides from one field: id. This deep dive walks through what the message actually says, why that is wrong for a tools/call, how the fix works, and the neighboring shape errors a senior interviewer will reach for next.
Reading the message the way the spec reads it
Here is the message under review, formatted for clarity:
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "read_file",
"arguments": { "path": "/etc/passwd" }
}
}
Every field present is valid. The jsonrpc member is the literal string "2.0", which the spec requires. The method names the operation. The params object carries the tool name and its arguments in the shape MCP expects for an invocation.
What is missing is id. And in JSON-RPC 2.0 that omission is not a minor stylistic gap. The presence or absence of id is the single bit that tells the receiver which of two contracts this message obeys. With no id, the spec classifies this as a notification, full stop.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Aspect | Request | Notification |
|---|---|---|
| id field | Present (integer or string) | Absent entirely |
| Server response | Must reply with same id | Must not reply |
| Use for tools/call | Correct, result is needed | Wrong, result is lost |
| Correlation | Reply matched by id | No correlation possible |
Real products, models, and research that use this idea.
- The MCP inspector traces JSON-RPC frames and flags a stalled call whose request was sent without an `id`.
- Claude Code multiplexes many tool calls over one stdio channel and uses the response `id` to route each reply to its caller.
What an interviewer would ask next. Try answering before peeking at the approach.
QIf a server receives this notification-shaped tools/call, what is the spec-compliant behavior?
It must not send a response. A conformant server treats a missing id as a notification, so the client stalls. Some servers reject unknown notifications, but staying silent is fully compliant.
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.
Assuming any message with a method is a request. Without an id, JSON-RPC 2.0 treats it as a notification and the server may stay silent.
60 second bullets to scan on the way to the call.
What single field distinguishes a request from a notification
Why a tools/call must be a request, not a notification
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.