Hosts, Clients, and Servers: MCP's Process Topology
A host never talks to a server directly, only through one client per server. That single binding is where MCP draws its trust boundaries, and where a host aggregating many servers has to start resolving name collisions. Name the three participants of an MCP system, host, client, and server, and state what each one is responsible for. Explain why a host embeds exactly one client per server connection instead of one client juggling several. Tell a local stdio server from a remote Streamable HTTP server and explain which boundary each one's trust actually follows. Match each server primitive, tools, resources, prompts, and completion, and each client feature to who controls it or who supplies it. Aggregate the tools of several connected servers into one registry, resolve a name collision with a server-id prefix, and explain why a server's self-reported serverInfo.name is never the key to route on. Picture an assistant wired into three systems at once: a files server, a notes server, and a metrics service. Every one of those connections carries the same stateless request shape you already know from the stateless core and the era-negotiation work in the lessons before this one: each request stamps its own protocol version and capabilities, and no connection remembers anything between calls. What those earlier lessons did not answer is a different…
Hosts, Clients, and Servers: MCP's Process Topology: A host never talks to a server directly, only through one client per server. That single binding is where…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.