The Model Context Protocol (MCP) defines a rigorous lifecycle for client-server connections that ensures proper capability negotiation and state management.
The initialization phase MUST be the first interaction between client and server. During this phase, the client and server:
The client MUST initiate this phase by sending an initialize
request containing:
The initialize request MUST NOT be part of a JSON-RPC batch, as other requests and notifications are not possible until initialization has completed. This also permits backwards compatibility with prior protocol versions that do not explicitly support JSON-RPC batches.
The server MUST respond with its own capabilities and information:
After successful initialization, the client MUST send an initialized
notification
to indicate it is ready to begin normal operations:
initialize
request.initialized
notification.In the initialize
request, the client MUST send a protocol version it supports.
This SHOULD be the latest version supported by the client.
If the server supports the requested protocol version, it MUST respond with the same version. Otherwise, the server MUST respond with another protocol version it supports. This SHOULD be the latest version supported by the server.
If the client does not support the version in the server’s response, it SHOULD disconnect.
Client and server capabilities establish which optional protocol features will be available during the session.
Key capabilities include:
Category | Capability | Description |
---|---|---|
Client | roots | Ability to provide filesystem roots |
Client | sampling | Support for LLM sampling requests |
Client | experimental | Describes support for non-standard experimental features |
Server | prompts | Offers prompt templates |
Server | resources | Provides readable resources |
Server | tools | Exposes callable tools |
Server | logging | Emits structured log messages |
Server | completions | Supports argument autocompletion |
Server | experimental | Describes support for non-standard experimental features |
Capability objects can describe sub-capabilities like:
listChanged
: Support for list change notifications (for prompts, resources, and
tools)subscribe
: Support for subscribing to individual items’ changes (resources only)During the operation phase, the client and server exchange messages according to the negotiated capabilities.
Both parties SHOULD:
During the shutdown phase, one side (usually the client) cleanly terminates the protocol connection. No specific shutdown messages are defined—instead, the underlying transport mechanism should be used to signal connection termination:
For the stdio transport, the client SHOULD initiate shutdown by:
SIGTERM
if the server does not exit
within a reasonable timeSIGKILL
if the server does not exit within a reasonable time after SIGTERM
The server MAY initiate shutdown by closing its output stream to the client and exiting.
For HTTP transports, shutdown is indicated by closing the associated HTTP connection(s).
Implementations SHOULD establish timeouts for all sent requests, to prevent hung connections and resource exhaustion. When the request has not received a success or error response within the timeout period, the sender SHOULD issue a cancellation notification for that request and stop waiting for a response.
SDKs and other middleware SHOULD allow these timeouts to be configured on a per-request basis.
Implementations MAY choose to reset the timeout clock when receiving a progress notification corresponding to the request, as this implies that work is actually happening. However, implementations SHOULD always enforce a maximum timeout, regardless of progress notifications, to limit the impact of a misbehaving client or server.
Implementations SHOULD be prepared to handle these error cases:
Example initialization error:
The Model Context Protocol (MCP) defines a rigorous lifecycle for client-server connections that ensures proper capability negotiation and state management.
The initialization phase MUST be the first interaction between client and server. During this phase, the client and server:
The client MUST initiate this phase by sending an initialize
request containing:
The initialize request MUST NOT be part of a JSON-RPC batch, as other requests and notifications are not possible until initialization has completed. This also permits backwards compatibility with prior protocol versions that do not explicitly support JSON-RPC batches.
The server MUST respond with its own capabilities and information:
After successful initialization, the client MUST send an initialized
notification
to indicate it is ready to begin normal operations:
initialize
request.initialized
notification.In the initialize
request, the client MUST send a protocol version it supports.
This SHOULD be the latest version supported by the client.
If the server supports the requested protocol version, it MUST respond with the same version. Otherwise, the server MUST respond with another protocol version it supports. This SHOULD be the latest version supported by the server.
If the client does not support the version in the server’s response, it SHOULD disconnect.
Client and server capabilities establish which optional protocol features will be available during the session.
Key capabilities include:
Category | Capability | Description |
---|---|---|
Client | roots | Ability to provide filesystem roots |
Client | sampling | Support for LLM sampling requests |
Client | experimental | Describes support for non-standard experimental features |
Server | prompts | Offers prompt templates |
Server | resources | Provides readable resources |
Server | tools | Exposes callable tools |
Server | logging | Emits structured log messages |
Server | completions | Supports argument autocompletion |
Server | experimental | Describes support for non-standard experimental features |
Capability objects can describe sub-capabilities like:
listChanged
: Support for list change notifications (for prompts, resources, and
tools)subscribe
: Support for subscribing to individual items’ changes (resources only)During the operation phase, the client and server exchange messages according to the negotiated capabilities.
Both parties SHOULD:
During the shutdown phase, one side (usually the client) cleanly terminates the protocol connection. No specific shutdown messages are defined—instead, the underlying transport mechanism should be used to signal connection termination:
For the stdio transport, the client SHOULD initiate shutdown by:
SIGTERM
if the server does not exit
within a reasonable timeSIGKILL
if the server does not exit within a reasonable time after SIGTERM
The server MAY initiate shutdown by closing its output stream to the client and exiting.
For HTTP transports, shutdown is indicated by closing the associated HTTP connection(s).
Implementations SHOULD establish timeouts for all sent requests, to prevent hung connections and resource exhaustion. When the request has not received a success or error response within the timeout period, the sender SHOULD issue a cancellation notification for that request and stop waiting for a response.
SDKs and other middleware SHOULD allow these timeouts to be configured on a per-request basis.
Implementations MAY choose to reset the timeout clock when receiving a progress notification corresponding to the request, as this implies that work is actually happening. However, implementations SHOULD always enforce a maximum timeout, regardless of progress notifications, to limit the impact of a misbehaving client or server.
Implementations SHOULD be prepared to handle these error cases:
Example initialization error: