What it does
The `notifications/initialized` notification is sent by the client immediately after it has fully processed the server's `InitializeResult` response. This marks the final step of the three-part MCP handshake: the client sends `initialize`, the server replies with `InitializeResult`, and then the client sends `notifications/initialized` to signal that both sides have agreed on a protocol version and capability set. Until the server receives this notification, it must treat the session as still in the initialization phase and must not send any requests or result-bearing notifications that depend on negotiated capabilities.\n\nThe server receives this notification and uses it as the transition trigger to move the session into the "running" state. In practice this means the server may now act on any capabilities it advertised, begin sending server-initiated requests such as `sampling/createMessage` if the client declared sampling support, and process pending work queued during initialization. The notification carries no parameters; its presence alone is the signal.\n\nOrdering guarantees matter here: the client must not send any non-initialization request before dispatching `notifications/initialized`, and the server must not dispatch capability-dependent requests before receiving it. This prevents races where, for example, a server attempts a `roots/list` call before the client has fully wired its roots handler. SDKs typically enforce this automatically by queuing outbound requests until the initialized notification has been sent or received on their respective sides.
When to use
Exactly once, right after receiving InitializeResult.
When NOT to use
Never re-send.
Notes
No capability declaration required
Unlike most notifications, `notifications/initialized` does not require either side to declare a capability before it can be used. It is a mandatory protocol message that every compliant client must send and every compliant server must accept. Skipping it is a protocol violation; servers that observe a client issuing regular requests before this notification arrives should treat the session as malformed.
Race condition window during handshake
Between the server sending `InitializeResult` and receiving `notifications/initialized`, a brief race window exists. Servers must buffer or defer any server-initiated requests they would normally send based on negotiated capabilities (e.g., `sampling/createMessage`). Sending such requests before the notification arrives can cause clients to reject them as out-of-order because their internal state machines have not yet transitioned to the running phase.
SDK handling differences
Most MCP SDKs (TypeScript, Python) send `notifications/initialized` automatically as part of their `connect()` or `initialize()` high-level call, so application code never needs to dispatch it manually. Lower-level or custom transport implementations must fire it explicitly. A common bug in hand-rolled clients is forgetting to send this notification, which leaves the server permanently blocked in the initialization phase waiting for the signal.
Ordering guarantee for client requests
The MCP specification forbids clients from sending any method call other than `initialize` before `notifications/initialized` has been dispatched. This is a strict ordering constraint, not merely advisory. Servers may safely assume that the first non-initialization request they receive arrives after this notification, and can use its arrival timestamp as a reliable lower bound for session-start telemetry and logging.
Examples
Initialized
{ "jsonrpc": "2.0", "method": "notifications/initialized" }