MCP server lifecycle: readiness through cleanup

Session and cleanup inputs

Computed lifecycle trace

Follow a version-pinned session

This lesson models the stdio handshake in MCP revision 2025-11-25. Its child process, messages and signal deliveries are deterministic fixture data; the browser launches no server. Read the state trace together with the selected message. Opening a transport is distinct from accepting a protocol version, declaring a feature and announcing readiness. The revision is pinned intentionally: this is not a claim about every later MCP lifecycle or SDK default.

Change the handshake gates

Server revision selects either the requested revision or an older revision that this particular client does not support. The older choice causes teardown without an initialized notification or tools request. Send initialized determines whether the ready notification appears after a compatible response. Disabling it leaves an incomplete session that this fixture abandons. Advertise tools changes the server response capability object. Disable only this feature to establish readiness while keeping tools/list unsent. These gates are independent; none grants authorization to a real tool.

Reproduce a deadline boundary

Tool-list response delay and Request timeout are modeled milliseconds. At defaults, the response delay is 1200 and the deadline is 2000, so request 2 receives a successful empty list. Increase delay to 2100 while preserving the deadline: the client instead emits notifications/cancelled for request 2, removes it from the pending set and begins teardown. Set delay to exactly 2000 to inspect the explicit tie policy: the fixture processes a response at the deadline before expiration. This ordering is a simulation choice, not a promise about concurrent network scheduling.

Inspect pending work and message identity

Next event advances exactly one recorded transition and pauses. At Send tools/list the pending request is 2; after a response or timeout it is null. Inspect JSON to compare request IDs with notification shapes. An empty tool list is a valid fixture result, not an error or an executed tool. Timeout means the client stopped waiting; cancellation does not demonstrate that a remote side has stopped. Late responses, cancellation races, progress resets and retries are outside this one-request model. Initialization always responds after a fixed modeled interval here; its own timeout failure is not simulated.

Compare three shutdown outcomes

Child exit behavior selects exit on stdin EOF, exit only after SIGTERM, or ignore both until SIGKILL. Shutdown grace interval controls the wait before each simulated escalation. With a 1000 millisecond grace, the outcomes add zero, 1000 or 2000 milliseconds of shutdown waiting. Try all three while keeping the handshake and response delay unchanged. The protocol result remains the same even when cleanup takes longer. After the final event the modeled child is gone, stdin is closed, readiness is false and no request remains pending. Signal names describe a POSIX-style scenario; Windows process handling and actual operating-system cleanup are not tested by this page.

Use replay without confusing two clocks

Play reveals the computed events across sixty inspection seconds. Pause freezes the current evidence; Speed selects half, normal or double viewing pace. Timeline scrubs and pauses, Restart rewinds the same inputs, and Finish reveals the last event. Restore defaults also restores normal speed. Every scenario control immediately rebuilds the trace and rewinds it, so a previous successful result cannot remain visible after a failed configuration is chosen. Backgrounding the page pauses playback. Events receive equal viewing slots for readability; their printed modeled millisecond timestamps retain the configured delay differences.

State the limits of the experiment

The model applies a strict local readiness gate for its ordinary request. It omits pre-readiness ping exceptions, HTTP sessions, authentication, capability extensions, multiple in-flight requests, real serialization and process I/O. The trace is fully available as text, and the message inspector does not depend on color. Use the related articles for broader architecture, then the versioned specification for wire requirements. Reproduce behavior against an actual SDK and target operating system before treating this educational fixture as implementation evidence.

Protocol reference: MCP 2025-11-25 lifecycle.