The Client: One Link Per Server

Inside the host lives the client. It is the piece that actually speaks the MCP protocol to a server. The host runs the show; the client does the talking.

Here is the key rule: the host creates one client for every server it connects to. Three servers means three separate clients running side by side.

Each client keeps a private, one-to-one connection with its single server. No client is ever shared between two servers.

Keeping links separate gives isolation. If one server crashes or misbehaves, its client fails alone and the others keep working fine.

When the model wants a tool, the host hands the request to the right client. The client formats it and sends it down its own connection.

Right after connecting, a client asks its server what it offers. It discovers the available tools, resources, and prompts before any are used.

A client sends a tools/list request to learn what it can call. The server replies with each tool's name and description.

A client tracks the live session: what was negotiated and which calls are in flight. It is the memory of that one connection.

The host runs all its clients together, then merges their tools into one menu for the model. You see a unified assistant; underneath sit many clients.

The host is the whole app and owns the model. A client is a smaller component inside it, dedicated to managing a single server link.

This one-link-per-server design keeps things simple and safe. Each client has one clear job, which makes the whole system easy to reason about.

Recall how many servers a single client connects to.

You saw the client: the host's protocol-speaker, one per server, holding an isolated session and discovering each server's tools. Great progress!