# MCP server architecture: hosts, clients, servers, and tools

> A practical map of MCP server architecture: the host application, one client per server, capability negotiation, tools, resources, prompts, and transports.

Web version: https://claw-link.dev/learn/mcp-server-architecture

MCP uses a host-client-server architecture. The host is the application a
person uses, such as an AI coding environment or desktop agent. It creates an
MCP client for each configured MCP server. Each client maintains its own server
connection, so one server does not automatically gain access to another server
or the whole conversation.

## The four parts

| Part | Job | Example |
| --- | --- | --- |
| Host | Manages the user experience, connection policy, and model | An IDE or agent application |
| MCP client | Maintains one connection to one MCP server | The host's Gmail connector client |
| MCP server | Exposes focused capabilities | A Gmail, filesystem, or internal-data server |
| Upstream service | Performs the real work behind the tool | Gmail API, database, or company API |

The official [architecture specification](https://modelcontextprotocol.io/specification/2025-06-18/architecture)
defines a one-to-one relationship between an MCP client and an MCP server. A
host can manage many clients, but each client has a separate stateful session.

## What moves across the connection

MCP has a data layer and a transport layer.

The data layer uses JSON-RPC messages for initialization, capability negotiation,
tool calls, resources, prompts, notifications, and progress. The transport layer
is how those messages travel. `stdio` connects local processes through standard
input and output. Streamable HTTP connects a client to a remote service with HTTP
POST and optional server-sent events.

During initialization, both sides say what they support. A client should not try
to call a tool when the server has not declared tool capability. A server should
not request a client feature that the client did not declare. This is capability
negotiation, not a cosmetic handshake. It prevents unsupported calls from being
treated as normal runtime failures.

## Tools, resources, and prompts

Servers can expose three core primitives:

- **Tools** are executable actions, such as search, send email, or query a
  database.
- **Resources** are data a client can read or attach as context.
- **Prompts** are reusable interaction templates selected by a user or client.

Tools are discovered with `tools/list` and invoked with `tools/call`. The tool
name, description, and input schema all matter because an agent uses those fields
to choose an action and form arguments.

## A request path

1. The host starts an MCP client for a configured server.
2. Client and server initialize, negotiate a protocol version, and declare
   capabilities.
3. The client requests `tools/list`.
4. The host gives the model the relevant tool definitions.
5. The model chooses a tool and arguments.
6. The client sends `tools/call` to the server.
7. The server validates access, calls its upstream system, and returns a result.

This is why a failed tool call can come from several places: the host, client,
server, credentials, input schema, network, or upstream app.

## Keep reading