Uzgadnianie inicjalizacyjne

Before any tool runs, client and server must meet. That opening exchange is the initialize handshake, and nothing else happens until it finishes.

The handshake always starts with the client sending an initialize request. The server stays quiet and waits to be greeted before it replies.

The client offers a protocolVersion so both sides speak the same MCP edition. The server confirms a version it can support in its reply.

Each side lists its capabilities, such as tools, resources, or sampling. This tells the other party which features it may safely use.

The client also sends clientInfo with its name and version. It is a friendly nameplate so the server knows exactly who connected.

The server replies with its own chosen version, its capabilities, and serverInfo. Now both sides know what the other can do.

After the reply, the client sends a final notifications/initialized message. It has no id and no answer, simply signaling that setup is complete.

Until that initialized notification arrives, the server should refuse other calls. The handshake gates everything that follows it.

Versions and features evolve, so the handshake lets a new client and an old server negotiate common ground instead of crashing on mismatch.

If the server never advertised resources, a polite client will not ask for them. Declared capabilities quietly define the rules of the whole session.

Remember the rhythm: client sends initialize, server responds, client confirms with initialized. Three beats and the connection is live.

What does the client send to finish the initialize handshake?

You traced the handshake end to end: the client offers a version and capabilities, the server confirms, and a final initialized note opens the session for real work.