Overview
A local stdio MCP server is a child process: the client starts it, stops it, and owns its failures. A remote Streamable HTTP server is a long-running service that many clients reach over the network, so it inherits the usual service obligations. This page covers the two that bite first: lifecycle management (startup, shutdown, health) and isolation between callers when one server instance serves many agents or organizations. For choosing a transport in the first place, see mcp-transports; for the wire mechanics of the remote transport, see mcp-streamable-http.
Manage server lifecycle: startup, shutdown, and health checks
For stdio servers, lifecycle is tied to the client process. The server starts when the client starts, receives SIGTERM or EOF when the client exits, and should flush logs and close connections in its shutdown handler.
For HTTP servers, treat startup and shutdown as first-class concerns. Provide a /health endpoint that returns 200 when the server is ready to accept connections. Wire a graceful shutdown handler that completes in-flight requests before stopping. Emit a structured startup log that records the server version, transport, and declared capabilities.
A server that starts slowly or crashes silently during development is invisible to the client until tool calls begin failing. Health checks surface problems earlier. Log the startup event with a timestamp so latency tracking can measure cold-start overhead.
Apply per-request or per-user isolation in multi-tenant HTTP deployments
When multiple agents share a single Streamable HTTP MCP server, state must be isolated. Rate limits, credential scoping, and audit logs must be keyed to the caller, not the server instance.
Under the current spec, derive the isolation key from the authenticated identity on each request (a bearer token subject, an mTLS client identity) rather than a connection-scoped session, since requests can land on any server instance. Validate it on every request. Store rate-limit counters and audit log entries under that key. Never allow one caller to read another’s state. Servers still on the 2025-03-26 through 2025-06-18 revisions use the Mcp-Session-Id assigned at initialize time as the isolation key instead.
Multi-tenant deployments also require care with secrets. A server that serves multiple organizations must scope credentials per organization at the request or user level, not at the server level. Mixing credentials across tenants is a data-isolation violation.
Keep per-caller state out of process memory
Store rate-limit counters, audit entries, and any cached per-caller data in a shared store keyed by caller identity rather than in the memory of one server process. The current spec has no connection-scoped session, so consecutive requests from the same caller can reach different instances behind a load balancer. State held in one process is invisible to the others and is lost on restart. Enforce the limits themselves as described in mcp-security.