Lifecycle of an MCP connection — Visual guide

Curso MCP Engineering · M1

This guide explains, from scratch and taking nothing for granted, how an MCP connection begins, lives and ends. Every connection goes through the same phases, in the same order: it's not optional or improvised. Understanding that order gives you a map to know, at any moment, at what point your connection is and what can or can't happen yet.

In one sentence

An MCP connection has a life cycle (lifecycle) of three fixed phases: initialization → operation → shutdown. Before working, the two parties have to greet each other and declare what they know how to do (the capability negotiation). The rule that governs everything: no one can use a feature that the other party didn't announce.

The three phases, in simple terms

1. Initialization — The client opens the connection and sends the initialize request. The server responds. In that back-and-forth they agree on the protocol version they'll speak and each one declares its capabilities. It's the "handshake": the greeting where both put their cards on the table. No real work happens yet.
2. Confirmation — The client signals it's ready with the notification notifications/initialized. Only now does the real work begin.
3. Operation — Requests and responses flow (tools/list, tools/call, …) and notifications (messages that expect no response). Only the capabilities that were negotiated in phase 1 are used.
4. Shutdown — The connection ends in an orderly way when it's no longer needed.

The phases at a glance

What "capability negotiation" is (and why it's mandatory)

A capability is a feature that one party declares it supports. During the 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, for this connection it doesn't exist.

Key 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 it 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, clarify "I speak Spanish, you speak English and French" — only then do they know in what language they can work.

The initialize sequence (illustrative example)

Note: this is an illustrative sketch, not the exact JSON on the wire. MCP uses JSON-RPC, and there responses don't carry a method of their own: they correspond to their request by the id field. That's why we mark them simply as result, and we don't invent names like initialize/result or tools/result (they don't exist).

// 1) The client greets and declares what it can do
--> initialize {
      "protocolVersion": "2025-06-18",
      "capabilities": {
        "sampling": {}        // the client DOES support sampling
      },
      "clientInfo": { "name": "mi-app", "version": "1.0.0" }
    }

// 2) The server responds and declares ITS OWN (it's the result of the previous request, correlated by id)
<-- result {
      "protocolVersion": "2025-06-18",
      "capabilities": {
        "tools": {}           // the server offers tools
      },
      "serverInfo": { "name": "mi-servidor", "version": "1.0.0" }
    }

// 3) The client confirms it's ready (notification: expects no response)
--> notifications/initialized

// 4) Now in operation: the client requests the list of tools...
--> tools/list
<-- result { "tools": [ /* ... */ ] }

// 5) ...and runs one
--> tools/call { "name": "buscar", "arguments": { /* ... */ } }
<-- result { /* result */ }

How to read the diagram

• --> is a message from the client to the server; <-- is from the server to the client.
• Each result is the response to the immediately preceding request. In real JSON-RPC they are correlated by id (same id in the request and in its response), not by the name.
• Notice the order: first they greet (steps 1-2), then it's confirmed (step 3) and only then does the work begin (steps 4-5). Before step 3 nothing useful runs.
• The server can only request sampling because in step 1 the client declared it. Without that line, there would be no permission.

Glossary

• Lifecycle: the fixed phases of a connection: initialization → operation → shutdown.
• initialize: the first request; the "handshake" where version and capabilities are agreed.
• Handshake: the initial greeting where both sides introduce themselves and declare what they can do.
• Capability: a feature that one party declares it supports. If it wasn't declared, it can't be used.
• Capability negotiation: the mutual agreement of which features each side enables. It's mandatory.
• JSON-RPC: the message format of MCP; responses are tied to their request by the id.
• Notification: a message that signals something but does not expect a response (e.g. notifications/initialized).
• Sampling: when the server asks the client to generate text with its model; requires that the client declared it.

To remember

• The order is always the same: greet → confirm → work → close.
• Capability negotiation is mandatory: if one party didn't declare a feature, the other can't use it.
• Example: the server can only request sampling if the client declared it in the initialize. Without a declaration, there's no permission.
• In JSON-RPC, responses are marked as result and correlated by id, not by invented method names.
• --> is client → server; <-- is server → client.

Turning Point Academy · MCP Engineering Course · Module 1 · Lifecycle of a connection