MCP client vs server: which are you building?
An MCP server exposes capability: tools a model can call, resources it can read, prompts it can use. An MCP client consumes that capability on behalf of an application, and it is always the client that opens the connection. A third role sits above both. The host is the application the user interacts with, and it owns the model, the interface and the consent decisions.
The naming runs opposite to the convention in web development. There, the server is the big shared thing and the client is the small local one. In MCP a server is frequently a small script running on your laptop as a child process, and the client is a connector inside a large application. Server means “offers capability”, not “is remote”.
What is the host, and why does it matter?
The specification names three:
| Role | What it is | Example |
|---|---|---|
| Host | The application the user interacts with. Owns the model, the UI and the consent decisions. | A desktop AI app, an IDE, an agent runtime |
| Client | A connector inside the host. One client per server connection. | The host’s connection to your filesystem server |
| Server | The thing offering tools, resources and prompts. | A filesystem server, a GitHub server, a remote API wrapper |
The host-to-client relationship is one-to-many: a host running six servers has six clients inside it. That is why “the client” is rarely a thing you install. You install a host, and it manages clients for you.
Which side initiates?
The client, always. It opens the connection and sends requests; the server answers them. Under the current 2026-07-28 revision the protocol is stateless, so each request is self-contained and carries its own protocol version and capabilities in _meta rather than negotiating once at the start.
Servers cannot call clients out of the blue. When a server needs something from the user mid-request, it does not open a channel: it returns an InputRequiredResult, and the client retries the original call with the answer attached. That is elicitation, and it is now the only client feature left, since sampling and roots are deprecated.
That direction constrains what a server can be designed to do. A server cannot issue a request to the client, poll a user, or start work on its own schedule. It can send notifications, such as notifications/tools/list_changed when its tool list changes, but only to a client that has opened a subscriptions/listen stream and asked for them. Even that is the client electing to receive something, not the server initiating. If you need a server to act on its own schedule, that belongs outside MCP.
Which one are you building?
Almost certainly a server. That is the common case by a wide margin, and it is the smaller job.
Build a server when you have a capability to expose: an internal API, a database, a service, a set of scripts. You define tools with JSON Schema, decide between a packaged distribution (runs locally over stdio) or a remote endpoint (HTTPS), and publish. Our build guides cover both across seven languages.
Build a client, or rather a host, only when you are building the application the user talks to. That means owning the model integration, the conversation, the consent UI, and the lifecycle of every server connection. It is a much larger undertaking than exposing a capability.
What does each side own, security-wise?
The split is not symmetric.
The server owns what it exposes and how honestly it describes it. Tool descriptions go into the model’s context, so they influence behaviour and are part of the security surface, not documentation. A server also owns its own supply chain: whether the published artefact matches its source, whether it carries known vulnerabilities, whether it runs anything at install time. Those are the signals we score.
The host owns everything about trust. Which servers to connect, what the user is asked to approve, whether a tool call proceeds, and what data goes to which server. It must treat every server’s output as untrusted content, because a tool result is third-party text heading into a model.
The client owns almost nothing in policy terms. It is a connector. Treating it as a security boundary is a mistake, because it faithfully relays whatever the server said.
So the asymmetry: a server can be well-built and still be dangerous to connect, and a host can make a poorly-built server safe by constraining what it may touch. Most of the leverage sits with the host.
Where to go next
- Building a server: build a secure MCP server from day one, then publish it.
- Deciding what to expose: what the Model Context Protocol is covers the three server primitives.
- Seeing the split concretely: point the MCP Inspector at a server; the Inspector is acting as a client, and everything it shows you is what a host would see.
Server means “offers capability”. Client means “consumes it”. Host means “decides whether any of it is allowed”. Most of the rest of MCP’s design follows from that split.