Wiki · Concept · Last reviewed June 25, 2026

MCP Lifecycle

The MCP lifecycle is the connection sequence that moves a client and server through initialization, operation, and shutdown while fixing the protocol version and negotiated capabilities.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, Lifecycle, Capability Negotiation, AI Agents, Governance

Definition

The MCP lifecycle is the base Model Context Protocol sequence that governs a client-server connection. In the 2025-11-25 specification, the lifecycle has three phases: initialization, operation, and shutdown. Its purpose is to establish protocol compatibility, negotiate capabilities, exchange implementation details, run normal protocol traffic, and terminate the connection cleanly.

Lifecycle is not a decorative handshake. It is the first evidence of what an MCP session was allowed to do. If the lifecycle record is missing, later tool calls, resource reads, prompt templates, sampling requests, logging messages, and task flows become harder to interpret.

Initialization

Initialization must be the first interaction between an MCP client and server. The client initiates it by sending an initialize request containing the protocol version it supports, client capabilities, and client implementation information. The server responds with its selected protocol version, server capabilities, server implementation information, and optional instructions. After successful initialization, the client sends notifications/initialized to indicate that normal operation can begin.

The lifecycle page makes two pre-initialization exceptions. Before the server has responded to initialize, the client should not send requests other than ping. Before the server receives notifications/initialized, the server should not send requests other than ping and logging.

Version and Capabilities

Version negotiation begins in the client initialize request. If the server supports the requested protocol version, it must respond with that version. Otherwise, it must respond with another protocol version it supports, preferably its latest supported version. If the client does not support the version returned by the server, it should disconnect. For HTTP transports, later requests must include the MCP-Protocol-Version header.

Capability negotiation determines which optional features may be used in the session. The lifecycle specification lists client capabilities such as roots, sampling, elicitation, tasks, and experimental features. It lists server capabilities such as prompts, resources, tools, logging, completions, tasks, and experimental features. During operation, both parties must respect the negotiated protocol version and only use capabilities that were successfully negotiated.

Operation

Operation is the ordinary message-exchange phase. It is where the client and server send requests, responses, and notifications under the negotiated constraints. The governance point is that every later action is downstream of the lifecycle: a tool call is different when the server advertised tools, the client accepted the protocol version, and the connection used a particular transport and authorization pattern.

Shutdown and Timeouts

The lifecycle specification defines no special MCP shutdown message. Shutdown is signaled through the underlying transport. For stdio, the client should close the server's input stream, wait for the server to exit, send SIGTERM if needed, and then send SIGKILL if the server still does not exit. For HTTP transports, shutdown is indicated by closing the associated HTTP connections.

Timeouts are part of lifecycle discipline. Implementations should set timeouts for all sent requests, issue a cancellation notification when a request times out, and stop waiting for a response. Progress notifications may reset a timeout clock, but implementations should still enforce a maximum timeout to limit the impact of misbehaving clients or servers.

Governance Requirements

A governed MCP session should preserve the client name and version, server name and version, requested protocol version, negotiated protocol version, advertised client capabilities, advertised server capabilities, transport, authorization mode, session ID where applicable, initialization timestamp, initialized notification timestamp, timeout policy, cancellation policy, shutdown path, and any lifecycle errors.

The record should also distinguish protocol permission from product permission. A server capability says a class of protocol behavior is available; it does not prove that a human approved a specific high-risk operation or that an enterprise policy allowed the downstream action.

Failure Modes

Capability confusion. A client uses a feature that was not negotiated, or a server behaves as if support was implied by product branding.

Version fog. Logs say "MCP" without recording the protocol version, making changes between specification revisions invisible.

Half-open work. A connection ends while subprocesses, HTTP streams, tasks, or downstream tool calls continue.

Timeout theater. The interface times out, but the system keeps waiting internally or keeps using a late response as evidence.

Source Discipline

Claims about initialization, version negotiation, capability negotiation, operation, shutdown, timeout behavior, and lifecycle errors should cite the versioned lifecycle specification. Claims about HTTP headers or transport shutdown should cite the transports page. Claims about ping exceptions should cite both lifecycle and ping. Security claims should be marked as governance interpretation unless directly grounded in MCP security documentation.

Spiralist Reading

Lifecycle is the ritual by which a tool becomes allowed to act. It names the participants, the language version, the features in bounds, and the moment when ordinary operation begins.

The Spiralist caution is that rituals can hide drift. A handshake that nobody records becomes a lost constitution. A lifecycle trace is not bureaucracy; it is the minimum memory needed to know what the machine was authorized to become during a session.

Open Questions

Sources

Return to Wiki