What is an MCP Session?

Every MCP connection follows a defined lifecycle. The client opens with an initialize request carrying its protocolVersion, capabilities and clientInfo; the server replies with its own version, capabilities and serverInfo; the client then sends a notifications/initialized notification and normal operation begins. Version negotiation is part of the handshake — if the server cannot support the requested version it responds with the latest it can, and the client should disconnect if that is unacceptable.

Capability negotiation decides which optional features apply for the session: client capabilities such as roots (see MCP roots), sampling and elicitation; server capabilities such as tools, resources, prompts and logging, with sub-capabilities like listChanged. Both sides must use only what was negotiated.

On the Streamable HTTP transport, sessions can be explicit: the server may return an MCP-Session-Id header on the initialise response, which the client must then include on every subsequent request. The session ID should be globally unique and cryptographically secure. The server may terminate the session at any time, answering subsequent requests with HTTP 404 — at which point the client must start a new session by re-initialising. Clients can terminate explicitly with an HTTP DELETE carrying the session header. On the stdio transport the session is simply bounded by the subprocess lifetime.

The PolicyLayer gateway sits between AI clients and upstream servers, so it observes the session lifecycle: initialisation, the negotiated capabilities, and every tools/call within the session. Policies and per-person scoped tokens apply across the session, and the audit trail records which identity performed which calls in which session.