What Is an MCP Host? Role, Responsibilities, and How It Works

An MCP host is the high-level AI application that coordinates multiple MCP clients to connect with external servers.

Claude Desktop, Claude Code, and Visual Studio Code are all hosts. The host is the central orchestrator, because it manages the lifecycle of every connection and folds the context it gets back from servers into the large language model's conversation flow, so that tools, resources, and prompts arrive in the structure the 2026-07-28 Model Context Protocol specification defines.

As the parent environment, the host keeps a registry of configured servers and instantiates one MCP client object for every dedicated connection. The protocol underneath has gone stateless, which means no session stays open between one request and the next, so the host is what stays standing: the runtime where agents operate, and the checkpoint that every byte from a local filesystem or a remote API clears before the model ever sees it.

The host is the UI mediation layer and the trust boundary, which makes it the place where a human says yes before a tool runs.

It brokers between the user's intent, the model's instructions, and the external data that servers provide, and if you get that layer wrong, no amount of clever server engineering rescues the product.

That architecture is a moving target. MCP versions its specification by release date, and the 2026-07-28 revision published by the Model Context Protocol maintainers is the current one as this article goes up, so it is the revision every reference below points at.

Illustration of an MCP host as the central AI application coordinating multiple connections to external data sources and tools

What is an MCP host?

An MCP host is the top-level AI application you open and type into, the one that kicks off the agentic work. Under the 2026-07-28 specification its architectural job is short to describe and long to build: keep a registry of configured servers, and instantiate individual MCP clients that each hold one dedicated connection. When Visual Studio Code acts as a host, for example, its runtime creates separate client objects, one for a local filesystem server and another for a remote service like Sentry.

The host is also where the model's capabilities actually happen, because it owns the context window that tools, resources, and prompts from every connected source have to share. The transport layer worries about bytes on a wire; the host worries about orchestration, so that the model sees one unified tool registry instead of a pile of unrelated connections it has to reconcile itself.

The host also carries the infrastructure for programmatic tool calling, usually called "code mode", where it converts tool schemas into typed APIs inside a sandbox so that the model can write and run real scripts against them. That leaves the host holding both ends of a mismatch: stateless protocol messages on one side, and on the other the stateful, interactive session the user believes they are having.

How do host, client, and server differ?

The MCP architecture has three participants, and the first two get mixed up constantly, so it is worth being pedantic once. The host is the parent application, such as Claude Desktop. The client is a protocol-level component living inside the host that manages exactly one connection to exactly one server. The server is the external program that supplies the actual context, such as database records or filesystem access, running either locally over STDIO or remotely over Streamable HTTP.

From the host's side the mapping is one-to-many, because a single host manages multiple clients and each client is tied to one server. Local servers typically use the STDIO transport to serve a single client, while remote servers on Streamable HTTP may serve many clients spread across different hosts. The split is what keeps the host responsible for the model interface while the client deals with the wire-protocol details, and it is the cleanest boundary the protocol draws.

MCP architecture diagram: one host containing several clients, each holding a dedicated connection to one server

A host typically configures these connections with a server parameters object. In the Python SDK, that means telling StdioServerParameters how to launch the server subprocess:

python

from mcp import StdioServerParameters
 
# Example host configuration for a local server
parameters = StdioServerParameters(
    command="python",
    args=["path/to/server.py"],
)

What does the host do during a tool call?

When the model decides to use a tool, the host intercepts that intent and takes over the execution. It routes the request to the specific MCP client attached to that tool's server, delivered as JSON-RPC 2.0 using the tools/call method, and it stays the arbiter of the exchange, because it checks the model's arguments against the server's inputSchema before anything runs — and models produce malformed arguments often enough that this unglamorous validation step is the single cheapest thing a host implementer can get right.

The host then receives the multi-format content array the server returns, which may include text, images, or embedded resources, and feeds it back into the model's context. If a tool call cannot finish without more information, the host runs the Multi Round-Trip Request (MRTR) flow, so it handles the InputRequiredResult, collects what is missing, and delivers the eventual inputResponses back to the server.

The host as gatekeeper in a tool call: it routes the request, checks arguments against the input schema, and returns the result to the model

A standard tools/call request and response handled by the host looks like this:

Request:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": {
      "location": "San Francisco",
      "units": "imperial"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

Response:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "Current weather in San Francisco: 68°F, partly cloudy."
      }
    ]
  }
}

The specification names the host as the final arbiter of user consent and security, because the host controls the UI mediation layer and sits on the boundary between the user and the model. Servers and individual clients cannot be the primary security enforcers, since they are often untrusted third-party code that should never get direct access to a user's authorization state, which makes this the part of the specification I would least like to see a host implementer skim.

The host must therefore implement the human-in-the-loop principle, with interfaces clear enough that a user can actually tell what they are authorizing. That matters most for tools with side effects, such as writing to a filesystem, moving money, or booking travel. Roots once provided advisory boundaries, telling a server which filesystem directories it should stay within, and they are now deprecated, because real security is enforced at the host and OS level through permissions and explicit user review — an advisory boundary was always just a polite request, and polite requests are not a security model.

The host also protects data privacy, since it must get explicit consent before exposing user data to a server, and it must not transmit resource data elsewhere without authorization. By running the MRTR flow, the host makes sure that any request for user input arriving as an InputRequiredResult is shown to the user before a response goes back.

What does a host offer back to servers?

Servers mostly provide context, but the traffic runs both ways: the host gives a server a way to ask for what it is missing, through elicitation delivered by the MRTR pattern. When a server reaches a point in a tool call where it needs more data, it returns an InputRequiredResult with resultType: "input_required", carrying one or more inputRequests. The host then gathers that information from the user and retries the original request with the inputResponses attached.

Multi Round-Trip Requests flow: the server returns an InputRequiredResult, the host collects user input, then retries the original request

Elicitation operates in two modes. In form mode the host renders a UI from a JSON schema to collect structured data, such as seat preferences. In URL mode the host hands the user a URL to open for out-of-band sensitive flows like OAuth, so that credentials never pass through the client, which is the right call: an AI application has no business watching your credentials go past.

The 2026-07-28 revision also deprecated three legacy client features, so every host has three migrations to plan. Sampling, the path by which a server could ask the host to run a model completion on its behalf, is deprecated, and new implementations should integrate directly with LLM provider APIs for completions. Roots goes the same way, because scope now travels in tool arguments, resource URIs, or server configuration. Logging is deprecated too, and the replacement is stderr over STDIO, or OpenTelemetry.

What did the 2026-07-28 spec change for hosts?

The 2026-07-28 specification made MCP a stateless protocol, because it removed protocol-level sessions along with the initialize/notifications/initialized handshake. For hosts, that means every request now has to introduce itself, which is what the _meta field carries: the protocol version, client capabilities, and client identity, attached to every outgoing request so that servers can process messages without holding connection state — more bytes on every single call, and a toll hosts pay gladly.

Comparison of the earlier stateful session model and the stateless model introduced in the 2026-07-28 specification

Caching had to fill the hole sessions left behind. List results for tools, prompts, and resources now carry ttlMs, a freshness hint, plus cacheScope, so that the host can cache tool catalogs and cut redundant tools/list calls. It also keeps the upstream prompt cache stable across network requests, which is the part that shows up in what you pay.

The revision also introduced header-based routing for the Streamable HTTP transport, requiring the Mcp-Method and Mcp-Name headers. Because of that, load balancers, gateways, and web application firewalls (WAFs) can route and rate-limit traffic on headers alone, without paying to parse the JSON-RPC body — a small change on paper, and a large one for anyone who has tried to put an MCP deployment behind the infrastructure they already run.

How does a host handle hundreds of tools?

Handing a model hundreds of tool schemas at once burns context and latency for no return, so a host implements progressive tool discovery instead, a three-layer pattern:

Catalog: the host exposes a search_tools meta-tool that the model calls to query the registry.
Inspect: the host fetches the full schema only for the tools the model identifies as relevant.
Execute: the model invokes the tool knowing its parameters.

The three layers of progressive tool discovery: catalog, inspect, then execute

Hosts may also implement programmatic tool calling, the code-mode route, in which the host converts MCP tool definitions into a typed API inside a sandbox. The model then writes a script that runs a sequential tool chain, such as filtering logs down to distinct errors, while the host brokers that sandbox, intercepting the function calls and routing them to MCP servers via tools/call.

In code mode the host also supplies helpers, including a host-brokered extract(value, ExpectedType) for un-typed outputs. Only the final summary reaches the model's context window, so the intermediate data never makes the trip, and the tokens those round-trips would have cost are never spent: a pile of raw logs goes into the sandbox, and a list of distinct errors comes out.

Should you build a host or use an existing one?

Building a custom MCP host is real work, mostly because of the stateless wire protocol and the MRTR pattern for InputRequiredResult handling. Most developers should therefore use the official SDKs, which shipped with the revision for TypeScript, Python, Go, and C#, with Rust in beta, because they already handle _meta fields, deterministic tool listings, and stateless transport logic for you.

Write your own host when you need specialized retrieval logic, domain-specific tool ranking, or deep integration into a bespoke runtime. Otherwise an established host like Claude Desktop hands you a production-grade implementation of the 2026-07-28 specification for free, and writing a second one mostly earns you your own copy of the _meta plumbing. The work worth doing is in the servers behind it.