TL;DR
In the Model Context Protocol, an MCP server exposes what a system can do (tools, resources and prompts) for AI applications to use. An MCP client is the connector inside an AI application, called the host, that talks to one server on the application's behalf. A host runs one client for each server it uses. The server offers capabilities; the client asks for them; neither checks whether the agent asked for the right thing.
Why the distinction matters
Getting the roles right tells you what to build. If you own a system that agents should be able to use, such as a database, a file store or a SaaS API, you build or deploy an MCP server. If you are building the AI application, you embed MCP clients, usually through an official SDK, and the host decides which servers to connect to.
What is an MCP server?
An MCP server is a program that wraps a system and describes what it can do in MCP's format. It can offer tools (functions the model can ask to run, each with a name, a description and a JSON Schema for its inputs), resources (data identified by a URI) and prompts (reusable templates). Under the 2026-07-28 revision of the specification, every server must also answer a server/discover request with the protocol versions and capabilities it supports. A server runs locally, launched by the host and talking over standard input and output, or remotely over Streamable HTTP. By design, a server receives only the requests sent to it and cannot read the whole conversation.
What is an MCP client?
An MCP client is created by the host and talks to exactly one server. It sends requests (list the tools, call a tool, read a resource), attaches the protocol version and its capabilities to every request, and hands results back to the host. The host is the application the user works in: Claude Desktop, an editor such as Cursor or VS Code, or an agent application you build. The host holds the model and the conversation, which is why the client is not the agent: it is a connector inside the application that runs the agent.
MCP server vs MCP client: side by side
| MCP server | MCP client | |
|---|---|---|
| Role | Exposes tools, resources and prompts | Requests them on the host's behalf |
| Lives | Next to the system it wraps, local or remote | Inside the host application |
| Usually built by | Whoever owns the tool or data | Whoever builds the AI application, via an SDK |
| Connections | Can take requests from many clients | Talks to exactly one server |
| Sees | Only the requests sent to it | What the host passes it |
How does a request flow between them?
- The client can call
server/discoverfirst to learn which protocol versions and capabilities the server supports. - The client calls
tools/list, and the host passes the tool descriptions to the model. - The model asks to use a tool, and the client sends
tools/callwith the arguments. - The server runs the tool and returns the result. If it needs something more, such as a confirmation from the user, it returns an "input required" result, and the client retries the original request with that input attached.
- The host adds the result to the model's context, and the model carries on.
The 2026-07-28 revision made MCP stateless: there is no opening handshake or protocol session, and every request carries its own protocol version and client capabilities. For servers reached over HTTP, the specification bases authorisation on OAuth 2.1; local servers take credentials from their environment.
What neither side can tell you
Look at the table again: the server sees only the requests sent to it, and the client passes along whatever the model asked for. So the server can confirm that refund_order ran with the arguments it was given, and the client can confirm the result came back. Neither can tell you whether a refund was the right action for that conversation, whether the amount matched what the customer was owed, or whether the agent called three tools when one would have done. That judgement needs the whole run: the conversation, the model's choice and every tool call it led to.
How Prefactor evaluates agents across MCP servers
Prefactor is an agent evaluation platform: it records every agent run, scores whether the agent did its job, and shows where to improve it. It works from the host side, where the whole run is visible.
One trace per run, across every server. Real-time tracing records every model call and tool call as a span as it happens, so the calls an agent makes to five different MCP servers appear in order inside one run. Instrumentation is a TypeScript or Python SDK, native for LangChain, Claude, Vercel AI, OpenClaw and LiveKit, or OpenTelemetry ingest. The MCP specification also documents a convention for carrying OpenTelemetry trace context in each request, for teams that want server-side spans joined to the same trace.
Scores on the steps that matter. Quality assessment scores each step of a run, so the wrong tool, the wrong arguments or a repeated call shows up where it happened. Comparing the same steps across versions and environments shows when a model or prompt change has shifted which tools get called.
A check before the call runs. Runtime policies evaluate a tool call against your rules before the server executes it, and approval routing can hold a high-risk call, such as a refund over a set amount, for a person to approve.
The quickest way to try this on your own traces is the open-source evals: deterministic checks for wrong tools, silent loops and half-finished runs, with no judge model and no token cost. To run the full loop on your own agents, start on the free tier: 5,000 spans a month at October 2026 pricing, no credit card required.