Can I skip initialization to save a round trip?

No. A client that skips it will typically see zero tools or get a protocol error, since the server hasn't yet declared what it supports.

What happens if the server doesn't support a capability the client expected?

The server simply omits it from its initialize response. The client should check for a capability before relying on it rather than assuming it's present.

Can a server's capabilities change mid-session?

Yes, via a listChanged notification. The client should re-run the corresponding list call rather than trusting its first snapshot for the whole session.

protocolTechArticle

MCP Connection Lifecycle

The initialize, discover, invoke, and terminate phases every MCP connection goes through, and what breaks when a phase is skipped.

Quick Answer / TL;DR

Every MCP connection goes through four phases in order: initialize (client and server exchange protocol version and capabilities), discover (client lists the server's tools, resources, and prompts), invoke (client calls them), and terminate (the connection closes). Skipping initialize is the most common cause of a client that connects but sees no tools.

Key Takeaways

The client must send initialize before anything else, and the server must respond with its actual capabilities before the client sends the initialized notification.
A server can add or remove capabilities mid-session by sending a listChanged notification; the client should re-list rather than caching the original discovery response forever.
MCP is stateless by design — don't rely on a server remembering anything about earlier calls in the same connection unless you've deliberately built that yourself.

Initialize and discover

The client opens with an initialize request declaring its protocol version and capabilities; the server responds with its own capabilities (which tool/resource/prompt types it actually supports) before the client confirms with an initialized notification. Only after that handshake should the client call tools/list, resources/list, or prompts/list.

json

// Client -> Server
{ "jsonrpc": "2.0", "id": 1, "method": "initialize",
  "params": { "protocolVersion": "2025-06-18", "capabilities": {}, "clientInfo": { "name": "claude-desktop", "version": "1.0.0" } } }

// Server -> Client
{ "jsonrpc": "2.0", "id": 1,
  "result": { "protocolVersion": "2025-06-18",
    "capabilities": { "tools": { "listChanged": true } },
    "serverInfo": { "name": "my-server", "version": "1.0.0" } } }

// Client -> Server (notification, no response)
{ "jsonrpc": "2.0", "method": "notifications/initialized" }

Invoke and terminate

Once initialized, the client can call tools, read resources, and fetch prompts freely and in any order. Termination differs by transport: a stdio server exits when its client process closes the pipe; an HTTP/SSE server closes the session on an explicit disconnect or a timeout.