MCP Host

The MCP Host is the application or runtime that connects to MCP servers and embeds them into an AI agent's tool surface. Examples in production today include Claude Desktop, Cursor, JetBrains IDEs with MCP extensions, LibreChat, WeKnora, and a long tail of custom enterprise agent runtimes built on top of the official MCP SDKs. The host is the trust authority — it decides which servers to connect to, what configuration to apply, and what actions the agent can take based on the connected servers' tools.

Architecturally, the MCP host plays three roles. It is the transport client, opening connections to local MCP servers via STDIO transport or to remote servers via HTTP/SSE. It is the tool aggregator, merging the tool catalogs from every connected server into the agent's working tool surface. And it is the execution authority, deciding when and how to invoke each tool, with the host's own privileges (credentials, file system access, network reach).

Why the MCP Host Is the Security Boundary

In the MCP threat model, the host is the security boundary. MCP servers run as child processes (STDIO) or remote endpoints (HTTP/SSE) and do not have an inherent permission system separating them from each other or from the host's environment. Whatever the host can do, a connected server can ultimately influence — by injecting prompt content into the agent's context, by returning crafted tool outputs, or, in the case of STDIO transport, by executing in the host's process space with the host's identity.

The April 2026 Anthropic MCP SDK disclosure, analysed in the Anthropic MCP SDK vulnerability writeup, made this concrete. Anthropic's position that the host process is the security boundary means every MCP host operator is responsible for enforcing the trust separation that the SDK does not provide — sanitising configuration before it reaches spawn calls, isolating servers in distinct process boundaries, restricting which environment variables propagate.

Practical Implications for Operators

Running an MCP host in production requires explicit decisions about three things:

Server selection. Which MCP servers will the host connect to? Pinned versions only, or auto-update? Signed packages only, or any registry source? The default in most consumer hosts (Claude Desktop, Cursor) is permissive — operators in enterprise contexts typically need to lock this down.

Privilege scoping. Each connected server gains effective access to whatever the host has access to. An MCP host running as the user's primary developer process inherits the user's git tokens, AWS credentials, and signing keys. Reducing this requires either running the host with constrained credentials or sandboxing child processes.

Tool trust. Tool catalogs from connected servers flow into the LLM's context. The host should sanitise descriptors before insertion, log full descriptor content per load, and diff against the previous run to catch post-install mutation.

For deeper background on MCP architecture, see the Model Context Protocol glossary entry. For the live record of host-impacting incidents, see the MCP Breach Index 2025–2026.