MCP Architecture Explained: Hosts, Clients and Servers

MCP has three roles. The host is the AI application the user runs. The client is a connector inside the host that holds one connection to one server. The server is a program that exposes tools, resources and prompts. Getting these three terms straight removes most of the confusion beginners have with MCP.

The host

The host is the application a person actually uses: a desktop chat app, a code editor with an AI assistant, a command-line coding agent, or your own custom agent. The host owns the conversation with the language model. It decides which servers to connect to, shows the user what is happening, and enforces policy such as asking for approval before a risky tool runs.

The model never talks to an MCP server directly. The host sits in the middle. It takes tool definitions from servers, passes them to the model through the model provider's API, receives the model's request to call a tool, and then forwards that call to the right server.

The client

Inside the host, an MCP client object manages one connection to one server. If the host connects to three servers, it creates three client instances. Each client handles the protocol details: the initialization handshake, sending requests, receiving responses and notifications, and closing the connection.

Because the relationship is one client per server, the servers are isolated from each other. A filesystem server cannot see the messages exchanged with a database server. The host is the only place where information from different servers can meet, and that is by design.

The server

An MCP server is a program that implements the server side of the protocol. It can run as a local process started by the host, or as a remote service reachable over HTTP. A server usually wraps something: a database, a folder of files, a SaaS API or an internal service. It declares what it offers, and it responds to requests.

Servers do not call the model themselves. Some servers can ask the host to run a model completion through a feature called sampling, but the host stays in control and can refuse.

How the pieces connect

+-----------------------------------------+
| Host (AI application)                   |
|                                         |
|  Model API <--> orchestration logic     |
|                   |         |           |
|             MCP client A  MCP client B  |
+-------------------|---------|-----------+
                    |         |
              stdio |         | Streamable HTTP
                    v         v
              Local server   Remote server
              (files)        (issue tracker)

Each line between a client and a server is a transport. Local servers usually use stdio, where the host launches the server as a child process and exchanges messages through its standard input and output. Remote servers use Streamable HTTP. The protocol messages are the same either way.

Who offers what

Servers offer three things to the host:

• Tools: functions the model can ask to run.
• Resources: data the application can read, identified by URI.
• Prompts: reusable prompt templates a user can choose.

Clients can offer features back to servers:

• Sampling: the server asks the host to run a model completion.
• Roots: the host tells the server which folders or URIs it should work within.
• Elicitation: the server asks the user for extra input through the host.

A walk-through of one request

Suppose a user asks, "What changed in the orders table this week?" and a database server is connected.

1. At startup the client connects to the server and asks for its tool list. The host adds those tool definitions to the model request.
2. The user sends the question. The host calls the model with the question and the tool definitions.
3. The model replies with a request to call a tool such as run_query with some arguments.
4. The host (optionally after asking the user) tells the client to send a tools/call request to the server.
5. The server runs the query and returns the result.
6. The host gives the result to the model, which writes the final answer.

Steps 2, 3 and 6 are the model provider's API. Steps 1, 4 and 5 are MCP. This split is important: MCP does not replace your model API, it standardizes the tool side.

Common misunderstandings

• "The server is where the AI runs." No. The server is a normal program. The model runs wherever the host calls it.
• "One client talks to many servers." In the protocol, one client holds one connection. The host manages many clients.
• "Local means no security concerns." A local server runs with the permissions of the user. A badly written one can read any file that user can read.

With the roles clear, the next post looks at what a server can actually offer: tools, resources and prompts.