In MCP, how is a notification different from a request?

Flashcard·Easy·4.0 · 0·~30s·Asked atComet Ml Robinhood Voyage Ai·Relevant atAnthropic

Attempt it

A notification is a JSON-RPC message with no id field. The sender does not expect a response and the receiver must not send one; it is fire and forget. MCP uses notifications for one way signals: notifications/initialized (client tells server the handshake is complete), notifications/tools/list_changed (server pushes a refetch nudge), notifications/resources/updated (resource changed), notifications/progress (long running call progress), and notifications/cancelled (abort an in flight request). Requests carry an id and always require a matching response.

Your answer

**A notification** in JSON-RPC is a message that looks like a request but has no `id` field. That missing `id` is the entire structural difference: the sender does not expect a response, and the receiver must not send one. It is fire and forget. MCP uses notifications for one way signals where a reply would add no value. `notifications/initialized` tells the server the handshake is done. `notifications/tools/list_changed` tells the client to refetch the tool catalog (only if the server advertised this capability). `notifications/resources/updated` signals that a subscribed resource changed. `notifications/progress` reports how far along a long running operation is. `notifications/cancelled` aborts an in flight request. Requests are the opposite: they always carry an `id` and always require a matching response. Sending a response to a notification is a protocol violation.

**A JSON-RPC notification** is a message with every field a request has except `id`. Omitting `id` signals no response expected; the receiver must not generate one. This is the fire and forget primitive of JSON-RPC 2.0, and MCP uses it for every one way signal in the protocol. MCP notification methods in the 2026 spec: - `notifications/initialized`: sent by the client immediately after the server responds to `initialize`. Signals the lifecycle handshake is complete and the server can accept other methods. - `notifications/tools/list_changed`: sent by the server when its tool set changes. Only valid if the server advertised `tools.listChanged: true` during initialize. The client refetches via `tools/list`. - `notifications/resources/updated`: sent when a subscribed resource changes (the client previously called `resources/subscribe`). The client re reads if it needs the new content. - `notifications/resources/list_changed` and `notifications/prompts/list_changed`: catalog change pushes, each gated by the corresponding `listChanged` capability sub flag. - `notifications/progress`: sent during long running operations to report progress on a `progressToken` the original request included. Either direction can emit these. - `notifications/cancelled`: sent when one side wants to abort an in flight request identified by `requestId`. The receiver should stop work. The distinction from requests is load bearing. Requests carry an `id`, expect exactly one response, and block the caller until they get it. Notifications carry no `id`, never receive a response, and complete the moment they are sent. If you need confirmation that the receiver processed the message, use a request instead.

TL;DR

A notification omits the `id` field, making it fire and forget with no response. MCP uses notifications for initialized, list changed pushes, resource updates, progress reports, and cancellation.

Memory aid

Easy to grasp

Think about sending text messages. Some texts are questions that need a reply: 'are you free tomorrow?' Others are just announcements: 'leaving now, on my way.' Requests in JSON-RPC are like the questions. They have a tracking number so the answer can be matched back. Notifications are like the announcements. You send them, the other person reads them, and that is the end of it. No reply needed, no reply allowed. MCP uses both kinds. Asking 'what tools do you have' is a request that gets a response. Telling the server 'I finished setting up' or being told 'my tool list just changed' is a notification: one way, no reply, fire and forget.

Key concepts

JSON-RPC Notification JSON-RPC Request Fire-and-Forget Messaging MCP Lifecycle

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.

Notifications are JSON-RPC's fire and forget message kind, and MCP uses them whenever the semantics are 'push this event' rather than 'do this and tell me when you are done.' They look like requests but omit the id, which is the structural signal that no response is expected.

This explanation covers the structural and semantic difference, walks through the notification methods MCP defines, explains how list change notifications are gated by capabilities, and closes with the correlation mechanisms for progress and cancellation.

Structural and semantic difference

JSON-RPC 2.0 defines three message shapes: request, response, and notification. Requests carry jsonrpc: "2.0", method, params, and an id. Responses carry jsonrpc: "2.0", the matching id, and either result or error. Notifications carry jsonrpc: "2.0", method, and params, but no id.

The missing id is the entire structural difference. It is also the complete semantic signal. With an id, the sender is asking for a response correlated by that identifier. Without an id, the sender is broadcasting a one way event that the receiver should handle but never reply to. JSON-RPC mandates this: a server must not send a response to a notification, and a client must not expect one.

The practical consequence is that notifications give the sender no acknowledgment. The sender does not learn whether the receiver got the message, processed it, or threw an exception while handling it. If you care about any of those outcomes, you must send a request instead.

This sounds limiting, and it is, but it matches a real class of semantics: events the receiver should observe and react to but where waiting for a reply would add no value. List changed pushes, progress updates, cancellation signals, and lifecycle ready signals all fit this shape.

MCP notification methods

Capability gating for list changed notifications

Correlation for progress and cancellation

Notification handling in practice

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Claude Desktop sends `notifications/initialized` to each MCP server after the initialize response and only then issues `tools/list`, following the lifecycle sequence.
A filesystem MCP server watching a directory emits `notifications/resources/updated` whenever a file changes; the host re reads the resource and can surface fresh content to the model on the next turn.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow does `notifications/progress` correlate to the original request?

The caller includes a progressToken in the original request's _meta field. Progress notifications echo the same token. The receiver matches by token to associate progress events with the correct in flight call. Multiple concurrent calls can each have their own token.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Expecting a response to a notification or trying to match it by `id`. Notifications have no `id` and never receive a reply; if you need confirmation, send a request instead.

60 second bullets to scan on the way to the call.

State the structural difference: notifications omit the id field while requests include it
State the semantic difference: notifications are fire and forget while requests block on a response

Primary sources. Browse if you want the original framing.