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.
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 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
- The host starts an MCP client for a configured server.
- Client and server initialize, negotiate a protocol version, and declare capabilities.
- The client requests
tools/list. - The host gives the model the relevant tool definitions.
- The model chooses a tool and arguments.
- The client sends
tools/callto the server. - 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.