DS DevShelfHub Projects · AI tools
Tutorials / MCP / Reference / Interfaces / JSONRPCNotification
Interface protocol modelcontextprotocol/types

JSONRPCNotification

By DevShelfHub

One-way message with no id and no expected response.

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

json
{
  "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.

Related

JSONRPCNotification FAQ

What is JSONRPCNotification in the MCP protocol?

JSONRPCNotification is an MCP interface type that defines the structure of protocol data exchanged between MCP clients and servers. It is part of the Model Context Protocol's JSON-RPC 2.0 message schema.

Which package provides the JSONRPCNotification type?

JSONRPCNotification is defined in the modelcontextprotocol/types package of the MCP TypeScript SDK. Equivalent types are available in the Python, Kotlin, Go, Ruby, and C# SDK implementations.

When should I use JSONRPCNotification in my MCP implementation?

Use JSONRPCNotification when your MCP host, client, or server implementation needs to work with this protocol structure. Refer to the When to use section above and the MCP specification for authoritative guidance.

What fields does JSONRPCNotification contain?

See the Fields table on this page for a complete list of fields in JSONRPCNotification, their types, whether they are required or optional, and their purpose.

Where can I find more MCP interface documentation?

The complete MCP API reference on DevShelfHub documents all MCP interfaces, methods, and notifications. Visit the MCP API Reference index to browse all types.