MCP Server Architecture, Transports, and Lifecycle
Snapshot
~85 sec
An MCP system has three distinct ownership boundaries: the host manages user experience and policy, each client manages one server connection, and the server exposes negotiated capabilities. Choose stdio or Streamable HTTP from deployment and trust needs, then design initialize, operation, timeout, cancellation, failure, and shutdown as one lifecycle.
You will learn
- Separate host policy, client connection state, and server capability ownership.
- Choose stdio or Streamable HTTP from deployment, identity, and exposure constraints.
- Trace negotiation, operation, cancellation, failure, and shutdown without assuming optional Tasks support.
Target outcome
You can sketch an MCP server architecture with explicit transport, lifecycle, capability, and failure boundaries.
Visual walkthrough
Visual walkthrough
~7 min
Five boundaries to design
Host policy
Owns configuration, user consent, model behavior, and which server connections are available.
Client session
Owns protocol negotiation and message exchange for one connected server.
Server capability
Owns the tools, resources, prompts, and optional features it declares and implements.
Transport
Carries protocol messages through a local process boundary or an HTTP service boundary.
Operation lifetime
Defines deadline, cancellation, result, error, and cleanup behavior for each request.
Choose the transport from the deployment boundary
Approach Process lifecycle Connection identity Exposure and trust Invented fit stdioThe client launches a local server process and exchanges messages over standard input and output. The client can tie the server process lifetime to one local connection. One launched process and its streams form a naturally narrow session boundary. No listening network endpoint is required, but the process still inherits meaningful local authority. A developer host launches an invented read-only console summarizer for one local practice project. Streamable HTTPThe client connects to an independently hosted HTTP endpoint that may serve longer-lived or multiple sessions. Server deployment and uptime are managed separately from any one client process. Authentication, authorization, session state, and request correlation need explicit design. The network boundary adds origin, credential, routing, and operational controls. An invented team build-status service exposes bounded read results to approved remote clients. Negotiate before operation; close deliberately
The client and server establish protocol version and capabilities before normal operations. Requests then run with bounded lifetime behavior until the connection shuts down.
MCP client
Initialize request
Client offers protocol version and its capabilities.
Initialized notification
Client signals that normal operation may begin.
Result or error
Client receives structured completion and decides whether another operation is valid.
MCP server
Initialize result
Server selects a compatible version and declares implemented capabilities.
Bounded operation
A discovered capability receives a request with timeout and cancellation handling.
Shutdown
Stop new work, settle or cancel active work, release resources, and close transport.
- Initialize requestInitialize resultoffers
- Initialize resultInitialized notificationagrees
- Initialized notificationBounded operationenables
- Bounded operationResult or errorreturns
- Result or errorShutdowneventually closes
The client and server establish protocol version and capabilities before normal operations. Requests then run with bounded lifetime behavior until the connection shuts down. Reading order
- Initialize request
Client offers protocol version and its capabilities.
- Initialize result
Server selects a compatible version and declares implemented capabilities.
- Initialized notification
Client signals that normal operation may begin.
- Bounded operation
A discovered capability receives a request with timeout and cancellation handling.
- Result or error
Client receives structured completion and decides whether another operation is valid.
- Shutdown
Stop new work, settle or cancel active work, release resources, and close transport.
Connection explanations
- Initialize request → Initialize result (offers)
The client cannot assume its preferred protocol version or optional capabilities are supported.
- Initialize result → Initialized notification (agrees)
The server response defines the version and capability surface for this connection.
- Initialized notification → Bounded operation (enables)
Normal requests begin only after initialization completes.
- Bounded operation → Result or error (returns)
Each request has a distinct completion path, including timeout, cancellation, or failure.
- Result or error → Shutdown (eventually closes)
Connection closure needs cleanup behavior even when the last operation succeeded.
Give every operation a terminal state
An invented asset-summary request must not remain ambiguous after its deadline, cancellation, transport loss, or server failure.
States
Queued
The server accepted the request but has not started project work.
Observable output: Request ID exists; no completion is reported.
Running
The server is reading the bounded invented asset set.
Observable output: Progress may be observable only when negotiated and implemented.
Completed
Structured summary and coverage evidence are available.
Observable output: One final result is returned.
Cancelled
Cancellation was requested and the server stopped at a defined boundary.
Observable output: No success is claimed; partial work is identified or discarded.
Failed
Validation, execution, timeout, or transport behavior prevented completion.
Observable output: A distinguishable failure is returned or the connection failure is surfaced.
Transitions
01
Queued → Running
- Input
- Capacity and request validation permit work.
- Effect
- The bounded operation begins.
- Result
- The request is no longer only queued.
02
Running → Completed
- Input
- Work finishes before deadline.
- Effect
- The server commits one structured result.
- Result
- Coverage and result fields are available.
03
Running → Cancelled
- Input
- Client requests cancellation.
- Effect
- The server attempts to stop at its declared cancellation boundary.
- Result
- Cancellation outcome is distinct from successful completion.
04
Running → Failed
- Input
- Deadline, validation, execution, or transport condition fails.
- Effect
- The operation stops or becomes unreachable without inventing a result.
- Result
- The client sees failure and does not blindly retry mutation.
Choose architecture and failure behavior
An invented local console reader is used by one developer process, while a team build-status service must serve approved remote clients. Which transport fits each, and what lifecycle behavior must both still define?
Expected reasoning
stdio is the smaller boundary for the client-launched local console reader. Streamable HTTP fits the independently deployed team service when its network identity, authentication, authorization, routing, and operations are designed. Both still negotiate protocol version and capabilities, bound every request with timeout and cancellation behavior, distinguish results from failures, and clean up deliberately on shutdown. Optional experimental Tasks are not required for either baseline.
Go deeper
- MCP 2025-11-25 specification: LifecycleCurrent initialization, capability negotiation, operation, and shutdown contract.
- MCP 2025-11-25 specification: TransportsCurrent stdio and Streamable HTTP framing, connection, security, and session requirements.
- Unity MCP 2.0 overviewUnity's official package architecture reference; the documented 2.0.0-pre.1 package remains pre-release and must be verified before production use.
- MCP 2025-11-25 specification: Tasks (experimental)Experimental task lifecycle model referenced by the architecture walkthrough; implementations need compatibility guards.