Put the MCP connection lifecycle steps in the correct order
- 1Client sends `initialize` request with `protocolVersion`, `clientInfo`, and `capabilities`
- 2Client calls `tools/call` to invoke a specific tool
- 3Client sends `initialized` notification to confirm it is ready
- 4Server responds with its own `protocolVersion` and `capabilities`
- 5Client calls `tools/list` to discover available tools
MCP opens with a three-message handshake: client `initialize`, server response, client `initialized`. Only then can capability requests like `tools/list` and `tools/call` proceed.
Think of plugging a new gadget into a universal hub. First the gadget says hello and lists what it can do; the hub says hello back and lists what it understands; then the gadget gives a final thumbs-up that it is ready. Until that little three-step greeting finishes, neither side knows the other's language version or features, so nobody tries to send real commands yet. The MCP handshake works the same way. The client asks first, the server answers, and the client confirms. Skipping or reordering those greetings means one side might speak a protocol version the other cannot parse, or call a feature the other never agreed to support. Order is the whole point.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Order questions on the MCP lifecycle look trivial until you ask why the order is what it is. The handshake is not an arbitrary ritual. It is the mechanism by which two independent processes, a host application and a capability server it may have never seen before, agree on a shared contract before they exchange any real traffic.
The sequence is fixed: the client sends an initialize request, the server responds, the client sends an initialized notification, and only then do capability-gated requests like tools/list and tools/call become legal. Get the order wrong and the session has no agreed protocol version, no agreed capabilities, and no readiness signal.
This deep dive walks each step, explains the two negotiations folded into the opening exchange, clarifies why initialized is a notification rather than a request, and shows what actually breaks when messages arrive out of order.
The three handshake messages, in order
MCP rides on JSON-RPC 2.0, which distinguishes requests (which carry an id and expect a response) from notifications (which carry no id and expect none). The lifecycle uses both kinds deliberately, and knowing which message is which kind is half the answer to an order question.
The connection opens when the client sends an initialize request. It carries three things: the protocolVersion the client speaks, a clientInfo block naming the client and its version, and a capabilities object declaring what the client supports. This is a request, so it has an id and the client blocks waiting for a matching reply before it does anything else.
The server answers with its own protocolVersion and capabilities, plus a serverInfo block. This response closes the first request-response pair and reuses the same id the client sent. At this moment both sides know the other's version and feature set, but the session is not yet open for normal traffic.
The client then sends an initialized notification. Because it is a notification, it carries no id and expects no reply. It is a one-way signal: 'I have processed your response and I am ready for normal operation.' These three messages, in this exact order, are the entire handshake. Everything else in the session, tool discovery, resource reads, prompt fetches, sampling, depends on those three having completed successfully first.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Step | Direction | Message kind | Purpose |
|---|---|---|---|
| initialize | Client to server | Request | Propose version and declare client capabilities |
| initialize response | Server to client | Response | Agree version and declare server capabilities |
| initialized | Client to server | Notification | Signal client is ready for normal operation |
| tools/list | Client to server | Request | Discover the tools the server advertised |
| tools/call | Client to server | Request | Invoke a specific discovered tool |
Real products, models, and research that use this idea.
- Claude Code spawns each configured MCP server, then runs the `initialize` handshake over stdio before it ever lists tools for the session.
- The mcp-inspector debugging tool shows the `initialize` request, the server response, and the `initialized` notification as the first three frames on every connection.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat should happen if the client and server propose different protocol versions?
The server returns a version it supports in its initialize response; the client either proceeds on that agreed version or disconnects if it cannot speak it.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Sending tools/list before the handshake completes, or forgetting the initialized notification. Both leave the session in an undefined state where capabilities are not yet agreed.
60 second bullets to scan on the way to the call.
Who sends the first message in an MCP connection
What the initialize request carries
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.