The problem MCP is for: MCP architecture

Covers: The problem MCP is for; Host, clients, servers; What a server offers: tools, resources, prompts.

The problem MCP is for

Before a standard, connecting N agent applications to M systems takes up to N × M adapters. With a standard, each application implements the client side once and each system implements the server side once: N + M.

Host, clients, servers

Host, clients and servers

The architecture has three roles, and the specification is precise about them:

Role	What it is	What it does
Host	the application the person uses (a chat app, an IDE, your agent)	creates and manages the clients; controls connection permissions; enforces security and consent; owns the conversation and the model; aggregates context from all clients
Client	a connector created by the host, one per server	talks to exactly one server; attaches the protocol version and capabilities to requests; routes messages both ways; keeps the servers apart
Server	a program or service that exposes capabilities	offers tools, resources and prompts; can be a local process or a remote service; must respect security constraints

Four design principles in the specification explain a lot about how the pieces behave:

Servers should be extremely easy to build. The host does the orchestration.
Servers should be highly composable. Many focused servers, combined by the host.
Servers should not be able to read the whole conversation, nor "see into" other servers. The conversation stays with the host, and cross-server interaction goes through the host.
Features can be added progressively. Capabilities are negotiated, so old and new software can meet.

The example checks the third one: after a run that used two servers, with a secret sentence in the conversation history and a calendar search for "dentist", neither server's log contains the secret, and the library server never saw the calendar query. The host held both. That separation is a design property you have to preserve in your own host: the moment you paste the whole conversation into a tool argument, you have broken it.

What a server offers: tools, resources, prompts

Primitive	What it is	Who decides to use it	Main messages
Tool	a function the model can call to do something	the model (with a person able to deny)	`tools/list`, `tools/call`
Resource	data that gives context, identified by a URI	the application (a picker, a search box, or automatic inclusion)	`resources/list`, `resources/templates/list`, `resources/read`
Prompt	a reusable template for a task	the user (for example a slash command)	`prompts/list`, `prompts/get`

The "who decides" column is the point. Tools are model-controlled. Resources are application-driven: the host decides how to bring them in. Prompts are user-controlled: they exist so that a person can pick a task. In the example, the host turns the prompts into commands (/library:reading_list, /calendar:plan_day) and lists the resources (a loan policy, and a template library://books/{isbn} for any book) for a person or the application to attach. Only the tools become part of the model's function list.

What a tool looks like on the wire

Messages are JSON-RPC 2.0: a request has an id, a method and params; a response has the same id and either a result or an error; a notification has no id and gets no reply. A tool definition is a name, a description and a JSON Schema for the arguments, just like the function schemas of Level 2:

> {"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"search","arguments":{"query":"science"},"_meta":{...}}}
< {"jsonrpc":"2.0","id":2,"result":{"resultType":"complete","content":[{"type":"text","text":"{\"results\": [...]}"}],
   "structuredContent":{"results":[...]},"isError":false,"_meta":{...}}}

A result can carry text content, and also structured content (a JSON value, which may follow an output schema); for compatibility a tool that returns structured content should also return it as text. The example returns both, and a test checks that they match.

Two kinds of error, and why the difference matters

Kind	Examples	How it is reported	Who can fix it
Protocol error	unknown tool, malformed request, server error	a JSON-RPC `error` with a code (`-32602` for an unknown tool)	usually not the model
Tool execution error	API failure, bad input, a business rule ("no copies available")	an ordinary result with `isError: true` and a text message	the model, if the text says what to do

The rule from the specification is to give the model the second kind, so that it can correct itself. This is the habit of telling the model what to do next: in the example, a checkout of an unavailable book returns No copies of 'Maps of Small Rivers' are available. Search for another title., and a badly formed date returns Date 'tomorrow' is not in YYYY-MM-DD form. Try again, for example 2026-11-03. Invalid arguments are also a tool error here (the schema checker names the missing argument) rather than a protocol error.