MCP Client vs MCP Server: Who Does What?
Short answer: the MCP server sits in front of a tool (your CRM, your database, a directory) and exposes what that tool can do. The MCP client lives inside an AI app and talks to the server on the model's behalf. You almost never install a client yourself: the app you already use ships with clients built in. That is the whole MCP client vs server split in three sentences.
The confusion usually comes from a third term the spec uses: the host. Once you see all three roles side by side, the picture stays put.
MCP client vs server: the three roles
MCP, the Model Context Protocol, is an open standard for connecting AI agents to tools. It splits the work across three roles, and each role has exactly one job.
The host is the AI application itself: Claude, an IDE assistant, an agent framework, your own custom agent. The host runs the model, decides when a tool call is warranted, shows the user what is happening, and enforces permissions. It is the part with a user interface and opinions.
The MCP client is a component inside the host. It manages one connection to one MCP server: it opens the session, fetches the server's tool catalog, forwards tool calls, and hands results back to the model. A host connected to five servers runs five clients, one per connection. You configure servers; the host spawns the clients quietly in the background.
The MCP server wraps one specific system and exposes its capabilities in the standard format: tools the model can call, resources it can read, prompt templates it can use. A CRM's server might expose search_contacts and create_deal. A database server might expose run_query. What a server looks like from the inside is its own topic, covered in [our guide to MCP servers](/blog/what-is-an-mcp-server).
One analogy, briefly: think of a restaurant. The host is the customer deciding what to order. The client is the waiter carrying the order to the kitchen and the plate back to the table. The server is the kitchen, the only part that actually cooks. Nobody expects the customer to fry anything, and the kitchen never takes orders at the table.
| Role | Where it runs | Who builds it | Example |
|---|---|---|---|
| Host | The AI app, on your machine or in the cloud | The app vendor, or you if you build agents | Claude, an IDE assistant |
| Client | Inside the host, one per server connection | Ships with the host, via the MCP SDKs | The connector Claude creates when you add a server |
| Server | Next to the tool, as a local process or remote endpoint | The tool's vendor, or the community | A CRM's MCP server, mcp.tulimoa.com |
"So Claude is my MCP client, right?"
Not quite, and this is the misunderstanding behind most MCP host vs client questions. Claude is a host with clients built in. When you add an MCP server to Claude, Claude creates a client for that connection internally. There is no separate "MCP client" program to download, which is why searching for one leads nowhere useful.
The other half of the confusion sits on the tool side. Your CRM does not run a client either. It runs (or should run) the server. The client always lives in the AI app; the server always sits with the thing being used.
So a typical setup involves three parties, and you only touch one of them. You tell the host which servers to connect to. The host manages its clients. The vendor operates the server. Done.
Who builds what
If you use an AI app: you build nothing. You add server entries to the host's configuration and the host handles the protocol. Adding Tulimoa's [live directory server](/mcp) is one config line, and read access needs no account.
If you ship a SaaS product: you build a server, never a client. Your customers' agents bring their own clients. Expose your core actions as tools with clear names and descriptions, and every MCP host out there can use them without custom integration work.
If you build your own agent: you are building a host, which means implementing the client side. The official SDKs handle sessions, discovery, and transport, so in practice this means instantiating one client per server and wiring the combined tool list into your model calls.
Worth noting the contrast with plain function calling, where every app hand-writes its own function definitions against each API. MCP moves that work to the server, once, for every client. The full comparison is in [MCP vs function calling](/blog/mcp-vs-function-calling).
One client per server, and why that number matters
Because a host runs one client per server, connections add up in a visible way. Ten servers means ten client sessions and ten tool catalogs loaded into the model's context before it reads a word of your prompt.
The roles compose, though. A single program can be a server on one side and a client on the other. That is exactly what an MCP gateway is: one server facing your agent, many clients facing the tools behind it. We wrote up [what an MCP gateway does](/blog/what-is-an-mcp-gateway) separately.
The takeaway that settles most of the confusion: hosts contain clients, tools sit behind servers, and the only thing you ever configure is the host.
Frequently asked questions
Is Claude an MCP client or an MCP host?
Claude is a host. It contains MCP clients, one for each server you connect. When people say "Claude supports MCP", they mean the host ships with the client side of the protocol already built in.
Do I need to install an MCP client separately?
No. Clients are components inside AI apps, not standalone programs. If your app supports MCP, the client is already there; you just point it at a server's endpoint or command.
Can one program be both an MCP client and an MCP server?
Yes. A gateway or proxy does exactly that: it presents itself as a single server to your agent while acting as a client toward the servers it federates behind that endpoint.
Who runs the MCP server for a tool like my CRM?
Ideally the vendor, as a remote endpoint you can point your host at. If the vendor does not offer one, community-built servers often fill the gap, usually run locally with your own API key.