What is MCP Host?
MCP Host is the user-facing AI application that creates and coordinates MCP Clients, assembles model context, and enforces application policy without replacing each MCP Server's authorization.
Quick Facts
| Specification | Official Specification |
|---|
How It Works
An MCP Host is the AI application at the top of the Model Context Protocol architecture. An IDE, desktop assistant, agent runtime, or custom product can be a Host when it creates MCP Clients, connects them to Servers, integrates an LLM, presents consent and results, and decides what context or actions are available. MCP standardizes context exchange between Clients and Servers; it does not dictate the Host's model provider, reasoning loop, memory, user interface, or context-management strategy.
Host, Client, and Server are logical roles even when one product packages them together. The Host owns the user-facing workflow and application policy. Each embedded MCP Client is the protocol adapter for one corresponding Server, and the Server exposes Tools, Resources, and Prompts. An AI Agent is behavior running inside or beside a Host, not a protocol role. A Gateway can mediate routing or organization policy without owning the model and user experience, while a Registry publishes discovery metadata without granting runtime trust. Treating these names as interchangeable hides the component that must make each security decision.
The 2026-07-28 protocol is stateless. A Host can still create one Client with a dedicated connection for each Server, but that Connection, stdio Process, or HTTP Stream is not a protocol Session, Conversation, User, or Task. Every Request carries its Protocol Version and relevant Client Capabilities in _meta; related work uses explicit Handles. The Client should include clientInfo, but it is self-reported display and debugging metadata, not an authenticated identity. Hosts supporting 2025-11-25 or earlier must isolate legacy Initialize, Session ID, capability, and server-initiated-request semantics from the modern path.
Server onboarding begins with configuration trust, not capability discovery. The Host verifies who supplied the endpoint or local command, its immutable package or deployment identity, update channel, transport, requested credentials, and allowed data boundaries. The embedded Client may call mandatory server/discover before other operations or send a direct Request and handle version errors. A successful response proves protocol compatibility, not provenance or approval. Self-reported serverInfo, icons, names, descriptions, Schemas, and links remain untrusted metadata.
The Host curates capabilities before exposing them to a model or user. It validates Schemas and content limits, maps each Server to a stable namespace, and resolves Tool and Prompt name collisions without relying on self-reported names alone. It stores discovery and list caches by configured Server identity, protocol revision, Authorization Context, cacheScope, and TTL; Change Notifications invalidate rather than authorize content. Descriptor or Schema changes can alter model behavior even when a name is unchanged, so consequential capabilities need hash comparison and re-review before re-enablement.
Context assembly is a privacy and reliability boundary. The Host retains the full conversation and sends each Server only the arguments, Resource identifiers, or other information needed for that Request. It decides which Resource bytes, Prompt Messages, Tool descriptions, and Tool results enter the model context; applies MIME, byte, token, provenance, and freshness checks; and prevents one Server from seeing another Server's credentials or private output by default. More context is not automatically better: oversized catalogs and results increase cost, reduce relevance, and widen the Prompt Injection surface.
Model selection is not authorization. Before a Tool call, the Host evaluates the configured Server, effective Tool revision, Principal, Tenant, arguments, purpose, side effects, data destination, and enterprise policy. Low-risk read operations may follow a pre-approved rule, while consequential writes should receive an argument-bound preview and explicit confirmation. Approval must show the real operation and destination, expire when material arguments or policy change, and remain revocable. The Server still enforces object-level authorization, idempotency, and transaction rules; a Host dialog, OAuth Scope, or Tool annotation cannot replace those controls.
For Streamable HTTP, the embedded MCP Client is the OAuth Client and the Server is the Resource Server. The Host provides the browser flow and credential vault while preserving a separate authorization transaction and token set for each user, Server, issuer, and target Resource. Validate Protected Resource and Authorization Server Metadata, exact Redirect URI, PKCE, state, issuer, Resource Indicator, token Audience, and challenged Scope. Reauthorization should request only the union needed for the current operation. Never reuse a token across Servers, put tokens in URLs or logs, pass a model-provider key to an MCP Server, or follow metadata and redirects into internal networks.
stdio uses process credentials rather than the HTTP OAuth profile and needs a different sandbox. Launch only reviewed binaries or packages with fixed executable and argument arrays instead of an interpolated shell command. Minimize environment variables, working directory, filesystem mounts, network egress, child-process permission, CPU, memory, output bytes, and runtime; keep protocol stdout separate from stderr logs. Pin package provenance and hashes, surface updates for review, and terminate the process tree on cancellation or shutdown. A local Server executes with local consequences and is not trusted merely because it uses a pipe.
MRTR makes the Host the mediator for additional input without giving the Server an unsolicited request channel. On prompts/get, resources/read, or tools/call, an input_required result can ask for supported Elicitation, deprecated Roots, or deprecated Sampling input. The Host checks declared capabilities, shows truthful origin and purpose, lets the user reject, obtains only necessary values, and sends an independent retry through the same Client. It echoes opaque requestState exactly without inspecting it and never treats it as authorization. New designs should prefer direct model-provider integration over legacy Sampling and explicit parameters or configuration over Roots.
Dynamic updates use explicit subscriptions/listen streams. The Host chooses each notification filter, verifies the acknowledged subset, correlates every event by Subscription ID, rate limits refreshes, and re-subscribes after a disconnect. Notifications can invalidate cached Tool, Resource, or Prompt catalogs, but they cannot silently grant a new capability or bypass review. Cancellation should propagate from UI and model timeout through Client, Server request, downstream work, and local process where possible; a closed stream does not prove a side effect was rolled back.
Every Server response is untrusted data. Tool descriptions can carry Tool Poisoning, Resources can carry indirect Prompt Injection, Prompts can alter instruction priority, and one compromised Server can try to influence selection or calls involving another. Keep Server outputs namespaced and provenance-labeled, separate instructions from data, prohibit automatic credential or context forwarding, and re-authorize every cross-server step. Sandboxing, human approval, a Gateway, or a stronger System Prompt each reduce part of the risk but do not turn model interpretation into a security boundary.
A production Host should trace the immutable Host build, user and Tenant, configured Server identity, Client instance, protocol era, transport, effective capabilities, descriptor or Schema hash, model and policy revision, selected primitive, redacted argument digest, authorization and approval decision, OAuth issuer and target Resource, MRTR step, cache and subscription event, latency, error class, cancellation, idempotency decision, and final effect status. Logs must exclude tokens, secrets, unrestricted conversation text, and raw sensitive Resource bodies. The Host is the coordination and application-policy boundary, not a universal trust oracle: Servers still validate requests, authorization systems still issue constrained credentials, and users must remain able to understand and stop consequential actions.
Key Characteristics
- Application coordinator: owns the user experience, model integration, context assembly, and policy decisions above MCP Clients
- One Client per Server: isolates protocol adapters and dedicated connections while keeping conversation and identity outside transport state
- Capability curator: namespaces, validates, limits, caches, and reviews Tools, Resources, Prompts, Schemas, and descriptor changes
- Credential boundary: separates OAuth transactions and tokens per user, issuer, Server, and target Resource, with distinct stdio credential handling
- Consent and execution governor: applies risk-based, argument-bound approval while preserving Server-side authorization and idempotency
- Cross-server security boundary: limits context propagation, contains local processes, labels provenance, and records end-to-end decisions without secrets
Common Use Cases
- An AI coding environment runs separate Clients for filesystem, source-control, and issue-tracker Servers while restricting each workspace boundary
- An enterprise assistant namespaces duplicate Tool names and exposes only policy-approved capabilities for the current user and Tenant
- A desktop Host launches a reviewed local Server with a minimal environment, filesystem allowlist, no shell interpolation, and process limits
- A remote Host completes per-Server OAuth with PKCE and Resource Indicators, then requests step-up Scope only for a selected operation
- A regulated Agent runtime previews consequential arguments, records approval and effect status, and prevents untrusted output from driving cross-server actions
Example
Loading code...Frequently Asked Questions
What is the difference between an MCP Host and an MCP Client?
The Host is the user-facing AI application that owns model integration, context assembly, consent, and policy. It creates one MCP Client for each Server; that Client handles the dedicated transport and JSON-RPC exchange. Products often package both roles together, but separating them identifies whether a failure belongs to application policy or protocol communication.
Is an MCP Host the same as an AI Agent, Gateway, or Registry?
No. An Agent is a decision-making workflow that may run inside a Host. A Gateway mediates traffic or organization policy, and a Registry publishes discovery metadata. Neither necessarily owns the model, conversation, or user interface. The Host can use all three, but it remains responsible for selecting context and enforcing application policy.
Can one MCP Host connect to multiple Servers in the stateless protocol?
Yes. The Host normally creates one Client with a dedicated connection for each Server. In 2026-07-28, that connection is not a protocol Session, Conversation, User, or Task; every Request carries its own version and relevant capabilities, and cross-request state uses explicit handles. The Host keeps names, credentials, caches, and outputs isolated by Server.
Does Host approval replace OAuth or Server authorization?
No. Host approval records informed user intent for a specific operation and arguments. The embedded Client still obtains audience-restricted OAuth tokens for remote Servers, and every Server must enforce Scope, Tenant, object, argument, purpose, and side-effect policy. Tool annotations, model selection, and a previous consent dialog are not authorization evidence.
How should an MCP Host secure local and remote Servers?
For local stdio Servers, pin provenance, avoid shell interpolation, minimize environment, filesystem and network access, enforce resource limits, and terminate process trees. For remote Servers, validate endpoint and authorization metadata, use PKCE, issuer and Redirect URI checks, bind tokens to the target Resource, and block SSRF. In both cases, namespace capabilities, inspect changes, constrain context, and keep outputs untrusted.