AI Systems Atlas

T-02MCP: Hosts, Clients, Servers

/tools/mcp

One protocol between the app that runs the model and the services that offer tools: the host starts a client per server, asks what each offers, and routes calls through it.

Step-by-step walkthrough8 steps
  1. The host is the app the user runs. The model lives inside it and never talks to a server directly.
  2. For every server, the host starts one client — one connection each, isolated from the others.
  3. A local server runs as a child process and talks over stdin and stdout.
  4. A remote one is reached over HTTP. Only the pipe differs; the messages are the same.
  5. On connect, the client asks what the server offers — its tools, resources and prompts — instead of assuming.
  6. Tool definitions travel up into the model’s context; a call travels back down the same client to the same server.
  7. Every connected server also writes text into that context. Connect one like a dependency, not a bookmark.
  8. Add or swap a server and nothing else changes — the protocol is the contract, not a bespoke integration per app.
Key insight

MCP turns every-app-times-every-integration into one implementation on each side. The transport is a detail — stdio for a local process, HTTP for a remote service — and the model sees tool definitions and results, never the server itself.

Failure mode

Treating a connected server as a trusted plugin. Every server writes text straight into the model’s context, and every tool it lists costs tokens on each request whether it is used or not.

Further reading
RelatedTool poisoningSkill & plugin supply chainTool search

Elsewhere in the atlas

Harnesses →Security →Evals →Context →Coding Agents →Ops →