Scope: a historical review of MCP 2025-06-18
This Explainer is a version-pinned historical review of the MCP specification dated 2025-06-18 [S1][S2]. Its initialization, session and shutdown statements refer to that release, not to whichever protocol version is latest when the article is read. Before applying them, identify the version supported by the selected client and server and consult its matching specification. The analysis examines why process, connection and session boundaries need separate attention; it is useful as a review of the selected historical design, not as a current-version migration guide.
Version selection matters here. The official 2026-07-28 changelog removes the initialize handshake, protocol-level Streamable HTTP sessions and the Mcp-Session-Id header, as well as SSE resumption and message redelivery [S3]. The historical mechanisms examined below must therefore not be applied as universal instructions for that later revision. A review of a legacy implementation should preserve its protocol and SDK versions alongside its observed behavior. This article explains the selected 2025 design; planning a migration requires a separate comparison against the target release and its implementation evidence.
The stdio Transport and Subprocess Mechanics
In the selected specification, the client launches the stdio server as a subprocess. Messages are newline-delimited UTF-8 JSON-RPC, with stdout reserved for MCP messages and stderr available for logs [S1]. A practical review should therefore inspect how the selected executable writes diagnostics. A readable log accidentally emitted on stdout is different from a valid protocol notification, even when both are useful to a human. The proposed test should record that distinction rather than assuming every printable line is a message.
Local process communication does not establish a complete operating boundary for the server's work. In this article's hypothetical design, a subprocess could also open a database connection or call an external API. Those activities would require their own review. Likewise, the team should test what happens when the parent process exits unexpectedly, rather than assume that every child process and external operation ends at the same instant. This is an engineering question for the chosen runtime, not a measured property of MCP.
Streamable HTTP Transport and Endpoint Architecture
Streamable HTTP uses an independent server and a single MCP endpoint supporting POST and GET. Responses can use JSON or an optional SSE stream [S1]. The proposed client review should exercise the response types that its selected implementation supports. Opening an HTTP connection, receiving an individual response and maintaining an application session are different observations. A diagram that treats them as one permanent channel can conceal which state survived a disruption and which state needs to be established again.
For an HTTP deployment, this article proposes documenting the server process, connection handling and any application state separately. A server may choose to maintain sessions, but a stateful design is not required merely because it uses this transport [S1]. The operator would also need to identify which intermediaries are present in the selected deployment. Load balancer and timeout behavior should be checked in that environment; this article does not infer those settings from the protocol or prescribe one universal gateway architecture.
Initialization Semantics and Capability Negotiation
Initialization begins with a client initialize request carrying a supported protocol version, capabilities and implementation information. The server responds with its version and capabilities; after success, the client sends notifications/initialized [S2]. A proposed connection record can retain the requested version, returned version and completion of that exchange. Reviewers should distinguish advertised optional features from the later contents of a tool catalogue. Negotiating a capability does not independently demonstrate the behavior, performance or suitability of every tool offered through it.
The initialization exchange is not authentication. This article's proposed review keeps caller identity and allowed actions separate from protocol version agreement. The lifecycle guidance recommends request timeouts and configurable handling; it does not establish one fixed number that fits every initialization or tool request [S2]. A team should record the values selected for its own implementation, the expected response when a timeout occurs and which external outcome may remain unknown. Passing initialization should not silently resolve any of those separate questions.
Session Identifiers, Expiration, and Reconnection
A Streamable HTTP server may assign an Mcp-Session-Id on the response containing InitializeResult. When it does, the client must send that identifier on subsequent HTTP requests. Following termination, a server returns 404 for the old session; the client must initialize a new session without that identifier [S1]. A proposed diagnostic record should distinguish this case from a missing endpoint or an intermediary error. The status code needs its request and session context before the operator chooses a recovery response.
SSE resumption is optional and uses event identifiers when implemented. A dropped connection is not, by itself, cancellation [S1]. This distinction leaves an application question: what happened to an operation whose response was not observed? The selected transport pages do not provide a universal business idempotency contract. In the proposed review, the operator would preserve the request and available outcome evidence before deciding whether another business action is appropriate. Resuming delivery and repeating an external action should remain separately documented choices.
Security, Origin Validation, and Transport Shutdown
A proposed stdio security review should identify which executable is launched, the permissions it receives and the environment passed to it. Local pipes do not create a sandbox or establish the trustworthiness of a binary. An implementation might deliberately restrict a subprocess, but that boundary would come from the selected operating environment and configuration. The review should therefore inspect those controls directly. Sensitive configuration should not be treated as harmless merely because it was delivered to a local process rather than through a remote endpoint.
The selected HTTP transport specification requires Origin validation on incoming connections [S1]. It does not impose a universal mutual TLS architecture. Shutdown is also transport-dependent: the lifecycle guidance describes closing the stdio child's input, waiting, and escalating to SIGTERM and then SIGKILL if necessary; HTTP shutdown closes associated connections [S2]. These are protocol guidance, not proof of successful cleanup in a particular operating environment. A proposed test should observe both process state and outstanding application work before declaring that a shutdown completed.
Proposed Diagnostic Scenarios and Lifecycle Design
For a clearly hypothetical diagnostic exercise, an engineering team could select a local fixture server that returns predetermined test data and makes no external calls. The client would launch it over stdio, exchange valid messages and observe where intentionally generated diagnostics appear. Keeping the fixture local is a condition of this proposed test, not a restriction imposed on every stdio server. No test was executed for the article. The expected record would distinguish message framing, process behavior and any remaining application question.
A second, unexecuted version of that hypothetical diagnostic exercise would use an independent HTTP server. The team would select whether to assign session IDs, interrupt a stream, and record the response to a request using an expired session. The expected observations would be compared with the selected specification, while external operation outcomes would be recorded separately. No resilience result is reported here: the exercise is a proposed way to expose implementation choices and unresolved state, not evidence that a system passed them.
Conclusion and Lifecycle Recommendations
A useful transport decision should explain the operating conditions it serves. This article does not prescribe stdio for every development use or HTTP for every production use. Instead, the proposed decision record names who launches the server, which communication path is used and which lifecycle state must survive a disruption. Conformance to the selected protocol release can be tested within that scope; seamless interoperability, safe tool behavior and successful recovery still need evidence from the implementations and workflows actually selected.
The proposed lifecycle record could include the negotiated version, the selected timeout behavior and the observations available after a process exit or lost connection. Each entry should name what remains unknown. A later implementation review would need actual test evidence before claiming a recovery or cleanup result. This keeps a useful protocol explanation separate from promises about an untested deployment. It also gives the team a concrete starting point for discussing which component owns an unresolved operation and which evidence is needed next.
Official background videos
External publisher context. These recordings do not demonstrate GPIRL products or validate the proposed designs.
- [Session] MCP Project Update with Jerome Swannack, Member of Technical Staff at Anthropic
Historical MCP project update from the 23 May 2025 summit, with an Anthropic project contributor. Background for the article pinned to specification 2025-06-18; transport and lifecycle requirements remain supported by that version of the specification. The recording predates the 2026-07-28 stateless revision and must not be presented as the current universal MCP lifecycle.
Sources and further reading
References do not imply product certification or endorsement.
Have a related operational question? Use the lifecycle questions to frame a focused architecture discussion.