MCP has three roles, and the trick is keeping them straight. The **host** is the application you actually open, Claude Desktop, Cursor, or your own app. It runs the conversation and shows you the approval prompts.
Inside that host live one or more clients. A client is a thin connector: the host spins up exactly one client for each server it wants to talk to. The client's only job is to manage that one JSON-RPC connection and shuttle messages back and forth.
A server is a separate program that exposes capabilities: tools the model can call, resources it can read, and prompts the user can pick. A filesystem server, a GitHub server, a Postgres server, each runs on its own.
So who enforces consent? The host. It is the only role that sees the user, so it is the only one that can ask 'do you approve this tool call?' and remember the answer. The server cannot enforce a policy it never sees, and the client is just plumbing. That is why the host owns orchestration and permissioning.
MCP defines three roles, and the host is the one that orchestrates and enforces consent.
The **host** is the user-facing application, Claude Desktop, Cursor, or a custom app embedding an LLM. It drives the conversation, decides which servers to connect, and gates every tool call behind user approval. Because it is the only role the user interacts with, it is the natural enforcement point for consent.
The relationship is one host to many clients to many servers. The host creates exactly one client per server connection. A client is a protocol-layer component that owns a single JSON-RPC session and its lifecycle. Clients do not make policy; they carry messages. Servers sit outside the host as independent processes.
Each server exposes tools, resources, and prompts, and may hold credentials for a backend API. But a server cannot enforce the user's consent policy. It has no view of the user and no authority over the workflow. The distractor options invert this. The server holding credentials does not make it the policy authority. The client managing the connection makes it plumbing, not a gatekeeper.
Quick reference
TL;DR
The host is the user-facing app that orchestrates the workflow and enforces consent; clients live inside it (one per server) and servers only expose capabilities.
Think of a power strip in your home. The strip is the host: it sits on your desk, you control it, and you decide which appliances get power. Each socket on the strip is a client: one dedicated socket per device, managing that single connection. The appliances plugged in are servers: a lamp, a charger, a fan, each offering one capability. The lamp cannot decide whether it is allowed to draw power, you do, by flipping the switch on the strip. In MCP, the host owns the same authority: it approves tool calls, enforces what the user permitted, and drives the conversation, while clients just carry messages and servers just offer tools.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Reasoning about a single-process app with no external capability providers If there are no separate servers, the host client server split collapses and the role distinction adds no value.
Designing a flow where the model itself approves its own tool calls Consent must sit at the host trust boundary; letting the model self-authorize defeats the entire permissioning model.
Pushing per-call authorization logic down into individual servers Servers may be untrusted or malicious; centralizing consent at the host is the only sound trust model under MCP.
Quick scan · 2–4 min
Everything important, quickly.
4 min: name the three roles, draw the one host to many clients to many servers topology, then argue why consent enforcement lands on the host and not the credential-holding server.
Side-by-side
Role
Where it runs
Owns consent?
Key responsibility
Host
User-facing app
Yes
Orchestrates workflow, gates every tool call
Client
Inside the host, one per server
No
Manages one JSON-RPC session lifecycle
Server
Separate process
No
Exposes tools, resources, prompts
Real-world examples
Real products, models, and research that use this idea.
1Claude Desktop acts as the host, spawning one client per configured server and prompting the user before each tool call.
2Cursor and Zed both function as MCP hosts, aggregating tools from multiple servers and enforcing their own approval UI.
3An Anthropic filesystem or GitHub server exposes tools and resources but defers every consent decision to the connecting host.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy does MCP isolate one client per server instead of multiplexing many servers over one client?
Sign in or go Pro to see the approach for this follow-up.
QIf the host is the only enforcement point, what attacks does that leave it exposed to?
Sign in or go Pro to see the approach for this follow-up.
QHow does the host surface tools from multiple servers to the model without collisions?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Assuming the server enforces consent because it owns the credentials. The server only offers capabilities; the host decides whether each call is permitted.