What is JSONRPCNotification?
JSONRPCNotification is a one-way message in the JSON-RPC 2.0 protocol: it carries a `method` name and an optional `params` object, but deliberately omits the `id` field. This absence is the defining contract — the sender fires the message and moves on; the receiver processes it but is explicitly prohibited from sending any response, result, or error back. In JSON-RPC 2.0 terms, a message without an `id` is a notification by definition, so any validating parser that sees a missing or null `id` alongside `method` must treat it as a notification rather than a request. \n\n Within MCP's message flow, notifications handle all asynchronous, push-style signalling where a round-trip would be wasteful or conceptually wrong. The `initialized` handshake confirmation, `notifications/progress` updates during long-running tool calls, `notifications/cancelled` signals, `notifications/message` log lines, and the family of `notifications/*/list_changed` events (tools, resources, prompts, roots) all travel as notifications. This keeps the protocol lean: progress streams don't block the originating request-response pair, and lifecycle signals don't require ACKs. \n\n The `params` field, when present, must be a structured object (not a positional array) per MCP convention. The `jsonrpc` version string must be exactly `"2.0"`. Both SDKs (TypeScript and Python) expose typed notification helpers so you rarely construct raw objects, but understanding the shape matters when writing custom transports, middleware, or test stubs that need to distinguish notifications from requests at the wire level.
When to use
Anytime you want to push information without expecting a reply.
When NOT to use
When you need confirmation or a return value.
Notes
No id means no response, ever
The JSON-RPC 2.0 spec is unambiguous: if a server or client receives a notification and sends back any response — including an error — it is a protocol violation. MCP validators and conformance tests check for this. When writing custom transport adapters, make sure your dispatch loop routes messages with no `id` to a fire-and-forget handler and never awaits a reply.
Params must be an object, not an array
MCP restricts `params` to a named-parameter object (`{}`) even though raw JSON-RPC 2.0 also allows positional arrays. Sending an array-shaped `params` will be rejected by the official TypeScript and Python SDK parsers with a schema validation error. Always use `{ ... }` for notification payloads.
Ordering is not guaranteed across transports
Over stdio the message order is preserved by the single-stream nature of the transport, but over HTTP/SSE the client-to-server channel and the server-sent-event stream are separate. Progress notifications sent on the SSE stream may arrive after the final tool result in edge-case network conditions. Design receivers to be tolerant of out-of-order or late-arriving notifications.
Distinguishing notifications from requests at runtime
Both requests and notifications share `jsonrpc` and `method`. The only reliable discriminator is the presence or absence of `id`. A strict parser should also reject `id: null` as a request (null id is not valid in JSON-RPC 2.0). When writing middleware that multiplexes multiple message types, check `'id' in message` rather than `message.id != null` to avoid misclassifying a notification as a malformed request.
Security: notifications bypass request authorization checks
Because notifications have no id and receive no response, some MCP server implementations skip per-notification auth checks that they apply to requests. Ensure your authorization layer inspects the `method` field on incoming notifications just as it would for requests — particularly for `notifications/cancelled` (which can abort ongoing operations) and any custom notification methods added by server extensions.
Fields
| Field | Type | Required | Purpose |
|---|---|---|---|
| jsonrpc | '2.0' | yes | Protocol identifier. |
| method | string | yes | Notification method name. |
| params | object? | no | Method-specific payload. |
Examples
Progress notification
{
"jsonrpc": "2.0",
"method": "notifications/progress",
"params": { "progressToken": "abc", "progress": 50 }
}
Common mistakes
❌ Adding an id to a notification
✅ Notifications have NO id — that's the whole distinction.