MCP Hosts, Clients and Servers: Who Does What

Status in the 2026-07-28 spec: core

An MCP setup has three roles. The host is the AI application you use. A client is a connector the host creates for one server. A server is a program that offers tools, data or prompt templates. Each host runs many clients, and each client talks to exactly one server.

The split matters for security. The host holds the conversation and the user's trust. Servers get only what they need, and they cannot "see into" each other.

This page follows the architecture section of the MCP specification, version 2026-07-28, as of October 2026.

What each role is

The spec overview gives one-line definitions:

The host and its clients live in the same application process. Servers can run on your machine or on the internet. If you connect three servers, the host runs three clients.

For a gentler walkthrough with diagrams in words, see our guide to how MCP works.

Why MCP splits the work this way

The architecture page lists four design principles. Two explain the split.

First, "servers should be extremely easy to build." The host handles the hard orchestration work, so a server can focus on one job.

Second, "servers should not be able to read the whole conversation, nor 'see into' other servers." The spec spells this out: servers receive only necessary context, "full conversation history stays with the host," and "cross-server interactions are controlled by the host."

This is the security model in one sentence. A weather server never learns what you asked your accounting server. Our guide on whether MCP is safe explains what that does and does not protect.

How each role works in 2026-07-28

The host

Per the spec, the host:

• Creates and manages multiple client instances
• Controls client connection permissions and lifecycle
• Enforces security policies and consent requirements
• Handles user authorization decisions
• Manages context aggregation across clients

The overview's security principles land on the host too. "Hosts must obtain explicit user consent before invoking any tool," and hosts must not send resource data elsewhere without consent.

The client

Each client "communicates with exactly one server." It "attaches protocol version and capabilities to every request," routes messages, manages subscriptions and notifications, and keeps security boundaries between servers.

Here is what that looks like on the wire. The client puts its version, identity and capabilities in _meta on each request. This example is adapted from the Streamable HTTP transport page:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "Seattle" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} },
      "io.modelcontextprotocol/clientInfo": { "name": "ExampleClient", "version": "1.0.0" }
    }
  }
}

The server

Servers "expose resources, tools and prompts via MCP primitives," "operate independently with focused responsibilities" and "can be local processes or remote services." The server features page adds who controls each primitive: prompts are user-controlled, resources are application-controlled and tools are model-controlled.

When a server needs input, it does not call the client. It returns a result marked input_required and the client retries. The spec says servers "request client input (sampling, elicitation, roots) via InputRequiredResult within a reply." See MCP multi-round-trip requests.

What changed across spec versions

The three roles have been the same since the first version. What changed is the relationship between client and server.

In the 2025-11-25 architecture page, each client "establishes one stateful session per server," and MCP was described as "a stateful session protocol." Capabilities were agreed once, at the start of the session, through an initialize handshake.

In 2026-07-28, the architecture page instead says "MCP is a stateless protocol: every request is self-contained and carries its own protocol version and capabilities." The base protocol page adds that an open connection "is not a conversation or session." Server-to-client requests were also replaced. Servers now ask for input inside a reply. Read why MCP became stateless for the reasons.

One small inconsistency: the 2026-07-28 architecture page still lists "sampling coordination" among host duties, even though Sampling was deprecated in the same release. The deprecated features registry is the authority on that.

Common mistakes

• Calling the AI app "the client." In MCP terms, the app is the host. The client is the per-server connector inside it.
• Sharing one client across servers. The spec defines a one-to-one client-server relationship.
• Letting servers see too much. Passing full chat history or another server's data to a server breaks the isolation principle.
• Treating the connection as a session. A stdio process or HTTP connection is not a conversation. Servers must not rely on prior requests for context.
• Skipping consent in the host. MCP "cannot enforce these security principles at the protocol level," so the host must build the approval flow.

Next step

Once you know who does what, the next question is how a client learns what a server offers. Read MCP server discovery. If you are planning your own server, our MCP development team can help.

Frequently asked questions