Lifecycle and capability negotiation

Lifecycle and capability negotiation (the initialize handshake)

Every MCP connection follows a lifecycle: an order of steps that always happens the same way. It's neither optional nor improvised. Understanding that order gives you a "map" so you know, at any moment, where your connection is and what can or can't happen yet.

What you'll learn

• The three phases of every MCP connection: initialization, operation, and shutdown.
• What capability negotiation is and why it's mandatory.
• Why a server can't use sampling if the client didn't declare it (the key example).
• The typical sequence initialize → tools/list → tools/call → notifications.

The three phases, simply

1. Initialization. It's the "greeting". The client sends an initialize request and the server responds. In that back-and-forth they agree on the protocol version they'll speak and each one declares what it can do (its capabilities). No real work happens yet: first they come to an agreement.
2. Operation. Now introduced, normal work begins: requests and responses (for example, "list the tools for me", "run this tool") plus notifications (messages that don't expect a response, like "something changed").
3. Shutdown. The connection ends in an orderly way when it's no longer needed.

What "capability negotiation" is (and why it matters)

A capability is a feature that one party declares it supports. During initialize, client and server put their cards on the table: "I can do this and this".

The golden rule is mandatory: neither party can use a feature the other didn't announce. If it wasn't declared, it doesn't exist for this connection.

Concrete example — sampling: sampling is when the server asks the client to generate text with its AI model. But the server can only request sampling if the client declared that capability in the initial greeting. Didn't declare it? The server has no permission to use it. This avoids surprises: each side knows in advance what it can count on. It's like two people who, before starting, say "I speak Spanish, you speak English and French" — only then do they know which language they can work in.

The typical sequence

After the greeting, a very common flow looks like this:

1. initialize — the greeting: version + capabilities.
2. tools/list — the client asks "what tools do you have?".
3. tools/call — the client says "run this tool with this data".
4. notifications — messages that flow during operation (for example, that the tool list changed).

Quick glossary

• Lifecycle: the fixed phases of a connection: initialization → operation → shutdown.
• initialize: the first request; the "handshake" where version and capabilities are agreed.
• Capability: a feature that one party declares it supports. If it wasn't declared, it can't be used.
• Capability negotiation: the mutual agreement on which features each side enables. It's mandatory.
• Sampling: when the server asks the client to generate text with its model; requires the client to have declared it.
• Notification: a message that reports something but does not expect a response.

To download

• 📄 Diagram — Lifecycle of an MCP connection (1-page PDF: the three phases and the initialize sequence).
• 📝 Lesson exercises (identify each phase and decide whether an action is allowed according to what was negotiated).

Before you continue

If you keep one idea: first they greet each other and declare what they can do; only after that do they work — and they never use something the other party didn't announce. In the next lesson we continue with the theory: transports —the "paths" (stdio and Streamable HTTP) these messages travel along. Building a server with code arrives in Module 2.