Click any words you think contain an error. Click again to unmark.
Mark at least one word to submit.
MCP runs on **JSON-RPC 2.0**, and that protocol has two kinds of message that look almost identical. A request has an `id` field and expects an answer back. A notification has no `id` and expects nothing back.
The message shown has a `method` of `tools/call` and some `params`, but no `id`. By the rules of JSON-RPC, that makes it a notification. The server is allowed to do the work and reply with nothing at all.
That is the bug. A `tools/call` is supposed to return a result, the output of running the tool. If the client sends it as a notification, it can never receive that output. Worse, the client may sit and wait for a response that the spec says it will never get.
The fix is one line: add an `id` field, for example `"id": 1`. Now the server knows this is a real request and will send a response tagged with that same `id`, so the client can match the answer to the call it made.
The bug is a missing id. The message has `jsonrpc`, `method`, and `params`, but no id field.
In **JSON-RPC 2.0**, the presence or absence of id is the only thing that separates a request from a notification. A request carries an id and the receiver must reply with the same id. A notification omits it, and the receiver must not reply. So this message, as written, is a notification.
That is wrong for a `tools/call`. Running a tool produces a result the caller needs back, so it has to be a request. Sent as a notification, the server is free to stay silent. The client then has no way to correlate any answer to this call.
The fix is one field. Add `"id": 1`, where the value is any integer or string unique among outstanding requests. Note that null is not a valid request id here. The id also drives correlation. A client multiplexes many in-flight calls over one connection. The matching id on each response is how it routes the reply to the right waiting caller.
Quick reference
TL;DR
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`.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
You genuinely want fire and forget with no reply expected Then omitting the id is correct; that is exactly what a notification is for, such as a progress or cancellation notice.
Sending a logging or progress message during a long tool run Those are legitimate notifications with no id; only the request-response calls like tools/call require one.
Emitting an initialized handshake notice after the initialize exchange The notifications/initialized message is a true notification and correctly omits its id, so adding one would be wrong.
Quick scan · 2–4 min
Everything important, quickly.
4 min: identify the missing id, explain request versus notification, the must reply versus must not reply contract, correlation over a multiplexed channel, and the other malformed shapes.
Side-by-side
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-world examples
Real products, models, and research that use this idea.
1The MCP inspector traces JSON-RPC frames and flags a stalled call whose request was sent without an `id`.
2Claude Code multiplexes many tool calls over one stdio channel and uses the response `id` to route each reply to its caller.
3Cursor and Zed, both MCP hosts in 2026, rely on the same `id` correlation when fanning out across multiple servers.
Interviewer follow-ups
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?
Sign in or go Pro to see the approach for this follow-up.
QHow does a client correlate responses when many tools/call requests are in flight at once?
Sign in or go Pro to see the approach for this follow-up.
QWhat other JSON-RPC shape errors should you watch for in MCP messages?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
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.