Initialization, Lifecycle, and Capability Negotiation
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
- The client sends an
initializerequest containing the protocol version, client information, and capabilities. - The server returns the selected version, server information, instructions, and capabilities.
- The client sends
notifications/initialized. - Normal operation begins.
- The connection ends through graceful shutdown or transport closure.
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 versionCapability 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.
Can you explain it without the notes?
Initialization, Lifecycle, and Capability Negotiation
Use your own words. Explain an example and one limitation before checking the explanation.
Check your explanation
Why it exists
Turn this concept into a clear answer.
Practice this conceptKeep connecting the ideas.
Next lesson: Tools: Discovery, Schemas, Invocation, and ResultsAdapted from 20_MCP_SERVER.md · “4. Initialization, Lifecycle, and Capability Negotiation”. Examples are study fragments; framework behavior can depend on your version.