MCP Host vs Client Distinction in Agent Architecture

MCP architecture has three distinct roles: host, client, and server. Each one carries responsibilities the others don't share, so mixing them up isn't just a vocabulary slip. It creates real gaps in how teams assign governance.

The host is the application a person actually interacts with. Claude Desktop, an IDE, an enterprise agent platform: these are hosts, and the host owns the model-facing experience, the conversation context, and the permission decisions that follow. The client is different. It's a protocol-level component that lives inside the host process, and it manages exactly one logical relationship with one MCP server, handling message construction, transport, capability discovery, and returning results. The server is a lightweight process that exposes specific tools, resources, or prompts, and does the actual work or delegates it.

These three roles don't map to three separate machines. A single host process can run several clients at once, each one talking to a different server. Picture a host that needs both a filesystem server and a GitHub server. It doesn't share one client across both connections.

The MCP client documentation draws the line directly: "the host is the application users interact with, while clients are the protocol-level components that enable server connections," and the rest of this piece rests on that distinction.

What the host owns

The host carries weight nothing else in the architecture carries. It's the only component that knows what the user actually wants, the only one that controls what the model gets to see, the only one that decides which server capabilities get exposed, and the only one with authority over consent and access.

Start with lifecycle. Clients don't spin themselves up. The host creates every client instance and manages it for as long as that session runs. A client exists only because the host decided it should.

Then there's exposure. A server can advertise a destructive tool, something that deletes records or sends irreversible commands, but the model only learns it exists if the host shows it. The host filters the menu before the model ever reads it.

Then there's mediation, and this is where the host's job gets concrete. The MCPblog architecture guide lays out what actually falls to the host: whether to show tool arguments before execution, whether to require a fresh approval when those arguments change, whether to apply an organization-wide allowlist. None of those three decisions belongs to the client. None belongs to the server either. They sit with the host because the host is the only party that can weigh user intent against organizational policy before anything executes.

A model doesn't normally open an MCP connection on its own. The host decides which server capabilities to reveal, translates between whatever tool format a given AI provider uses and the MCP standard, asks the user to confirm, invokes the client, and decides what to do with whatever comes back. A server, for its part, never sees the full conversation by default. It gets only the arguments, context, credentials, and metadata that the host and client choose to pass along.

Run through a simple example. A user asks an application to open an issue in a code repository. The host reads that request, applies whatever policy governs repository writes, and then decides whether to proceed. The client carries the formatted request over to the server. The server validates it and performs the operation. Three stages, three separate owners, and the host holds the policy decision at every step.

This is precisely where governance has to live, because the host is the only component positioned to answer it. Control for MCP gateways therefore has to sit at the host, not inside the client or the server. If you enforce policy from the client's side, you enforce it only after the exposure decision has already been made.

What the client owns

The client's job is narrow by design. One client handles one connection to one server. When a host needs to talk to several servers at once, it doesn't stretch a single client across all of them. It spawns a new client instance for each server, and that one-to-one mapping keeps every connection isolated, so state from one server can't leak into another.

Skyvern's MCP architecture explainer, published 2026-05-16, describes the client as holding "exactly one connection to one MCP server, handling the protocol-level message exchange so the host logic stays clean". That phrase, "so the host logic stays clean," says something important: the client's narrowness isn't an accident or a limitation. That way, the host can focus on intent and policy without getting tangled in transport details.

If a tool call is running, a server can send a structured request for user input through elicitation. Even here, though, the client stays inside its lane: it controls what information actually reaches the server and checks the response before handing it back. It's a gatekeeper for one narrow corridor, not a decision-maker for the whole building.

The protocol itself is tightening this boundary further. The official MCP client documentation lists sampling and roots as deprecated as of protocol version 2026-07-28, which signals that the client's feature surface is shrinking toward pure protocol mediation rather than expanding. The direction of travel is clear: the client handles the wire-level exchange, and everything resembling a judgment call moves toward the host.

That split matters because it's deliberate. Separating "which server am I talking to and how" from "should this action happen at all" is what lets a host swap servers, add new ones, or revoke access to one without touching how it reasons about user intent. The risk isn't that the client does too little.

Conflating host and client displaces accountability for access control

The confusion is understandable before it's a problem. Host and client often run in the same process, and a developer working with an SDK may interact with both through a single interface, with no clear seam marking where one role ends and the other begins.

That's a workable arrangement for building software quickly. It's a bad arrangement for assigning accountability. When a security team sets out to audit "the MCP client," what they're usually looking at is message transport and server capability negotiation, the narrow protocol lane. Meanwhile the host's actual decisions, what gets exposed to the model, which actions require a fresh confirmation, how organizational policy gets enforced, go unexamined. The audit happens and a report gets filed, but no one looks at the part of the system that actually makes judgment calls.

The host is where user authorization decisions live, and if no one owns that policy surface by name, those decisions default toward permissive. Whatever the server advertises reaches the model, because nobody drew a line to stop it. This isn't a hypothetical gap in an org chart.

There's a second effect, harder to see but just as consequential. MCP cleanly separates the LLM host from the executing tool server, which lets backends get swapped or extended without touching the agent itself. That's elegant engineering. It also quietly moves the trust boundary onto the host, and most enterprise teams haven't caught up to that shift.

When teams blur the host-client boundary, accountability for policy enforcement turns ambiguous: does the client enforce the rule, or does the host?

Documented threats that exploit the ungoverned host permission surface

An ungoverned host permission surface isn't a theoretical risk. It has a track record.

In September 2025, a counterfeit email server MCP package, impersonating the legitimate postmark-mcp library, shipped an update carrying a hidden backdoor. Once installed, it silently BCC'd every agent-sent email to a domain controlled by the attacker. The attack surface opened the moment the tool's description entered the model's context, and the damage compounded because the MCP servers involved carried elevated privileges across multiple connected systems. None of that required breaking the protocol. It required a host that exposed a tool's description to the model without a second check on what that tool actually did.

Credential aggregation follows the same pattern. If a single host connects to servers holding credentials for Slack, GitHub, Postgres, and Salesforce, one compromised server connection can reach all four. The host controls which servers get connected and what credentials flow between them, so this is a host-governance failure, not a flaw in any one server.

The confused deputy pattern works the same way. A server with ambient authority gets manipulated into taking unauthorized action, and that happens because the host granted broad permission scopes without requiring a check at the level of each individual action. The server has been handed more authority than any single request needed, and nothing at the host level narrowed that authority down.

The protocol itself has started responding to this. MCP servers are now formally defined as OAuth 2.1 resource servers, and they're required to implement OAuth 2.0 Protected Resource Metadata under RFC 9728, so a client can automatically discover the correct authorization server. The 2026-07-28 spec goes further and explicitly forbids token passthrough: forwarding an upstream token straight into a downstream tool call, instead of using OAuth 2.0 Token Exchange under RFC 8693, lets a credential issued for one audience reach systems it was never meant to touch. The corrected pattern puts token exchange inside the MCP server, handled per operation, so one token doesn't wander across trust boundaries it wasn't scoped for.

The spec being clear doesn't mean practice has caught up. A large number of active MCP servers sitting on the public internet run with no authentication at all, which older spec versions technically allowed but which leaves them practically wide open.

Research scoring agent protocols against a six-dimension governance taxonomy found every protocol examined, MCP included, scoring poorly across the board: human escalation was absent everywhere, and audit mechanisms were missing or partial for most of the protocols reviewed. For MCP specifically, there's no protocol-level way to route a decision to a human based on a confidence threshold or a risk score. MCP's Elicitation feature can ask a user for input mid-execution, but that's a request for information, not a governance checkpoint, and it leaves no record of why a host allowed or denied a given action. A separate paper, "Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express," names the absence of standardized governance and audit mechanisms as a systemic gap running across every major agent protocol, not something unique to MCP.

None of this erases the value of the host-client split. It sharpens what that split demands of the teams running these systems. The spec now distinguishes what belongs to the client, token scoping, resource indicators, from what belongs to the host, policy decisions, identity checks, the call on how a token gets exchanged.

Runlayer, an enterprise AI control plane and MCP gateway used by companies like Gusto and PagerDuty, makes the host's policy decisions explicit, because it enforces governance and audit at the tool-call level across every agent session. The host owns the decisions that matter: what the model sees, what gets confirmed, what gets blocked. The governance requirement goes unmet if those decisions stay invisible, even when the engineering team can correctly diagram a host versus a client.