Host, client, server
The host is the AI application itself — the chat app, the IDE, the agent runtime. It embeds an MCP client per server connection, and each client speaks to exactly one server. The separation matters operationally: a host with five integrations holds five client connections, each scoped to its own server, rather than one tangle of glue code. Servers, for their part, know nothing about each other; composition happens in the host, where the model sees the union of all connected tools and chooses among them.
Tools, resources, prompts
A server offers three primitive types. Tools are model-controlled: functions the model may call, defined by a name, a description, and a JSON schema for parameters — and those descriptions are live interface, since the model chooses tools by reading them. Resources are application-controlled: content the host can pull into context, addressed by URI. Prompts are user-controlled templates the server suggests. Most operational attention lands on tools, because tools act — and the description-plus-schema contract is where most quality and safety problems originate.
Sessions and transports
Client and server begin with a capability negotiation — what each side supports — then exchange JSON-RPC messages over one of two transports. stdio runs the server as a child process of the host: simple, local, inheriting the user's permissions. Streamable HTTP makes the server a network endpoint that can serve many clients, with OAuth as the specification's authentication answer and the usual obligations of an exposed service. Notifications flow back the other way — a server can tell connected clients its tool list changed, which is also why a server update is a behaviour change for every agent attached to it.
What the architecture means for you
Two consequences follow from the shape. First, the server is the natural control point: permissions, rate limits, result caps, and logging all belong there, enforced regardless of which agent calls. Second, the host is where risk composes — a model holding tools from a finance server and a web-reading server simultaneously can be steered by one to misuse the other, which is why securing the layer means thinking about the combination, not each server alone. The build and security guides turn both consequences into concrete work.