Foundation·Concept·2 min read

Initialization, Lifecycle, and Capability Negotiation

Practice this question

Why it exists

Clients and servers may support different protocol versions and features. Initialization allows them to agree on a common contract before normal operations begin.

Lifecycle

  1. The client sends an initialize request containing the protocol version, client information, and capabilities.
  2. The server returns the selected version, server information, instructions, and capabilities.
  3. The client sends notifications/initialized.
  4. Normal operation begins.
  5. The connection ends through graceful shutdown or transport closure.
Architecture at a glanceFollow the arrows to see how the parts connect.

Preparing the architecture diagram…

Read the full diagram flow
stateDiagram-v2
  [*] --> Initializing
  Initializing --> Operating: initialize response + initialized notification
  Operating --> Closing: shutdown or transport close
  Closing --> [*]
  Initializing --> [*]: incompatible version

Capability negotiation

Capabilities are promises. A client should expect tool operations only when the server advertises the tools capability. Resources may advertise subscriptions, while list capabilities may advertise listChanged notifications. Calling an unsupported feature is a compatibility bug.

Interview point

A version number alone is not enough. Code should check negotiated capabilities because optional features are not available in every client/server pair.

Adapted from 20_MCP_SERVER.md · “4. Initialization, Lifecycle, and Capability Negotiation”. Code examples are study fragments. Difficulty and core labels are editorial estimates; version-specific behavior should be checked against your project.