MCP Client vs Server vs Host: The Model Context Protocol Architecture Explained

Direct answer

For the request mechanics, use the shorter how MCP works guide; for the protocol-level definition, start with what MCP is.

An MCP host is the user-facing AI application or agent environment. It owns the model-facing experience, conversation and working context, permission interfaces, cross-server orchestration, and the lifecycle of the MCP client components it creates. An MCP client is the protocol component the host uses for one logical relationship with one MCP server. It constructs and parses MCP messages, handles the selected transport, carries protocol version and client capabilities, discovers server capabilities, and returns results to the host. An MCP server implements the server side of the Model Context Protocol and exposes focused capabilities such as tools, resources, prompts, or negotiated extensions. The server executes operations itself or delegates them to an API, database, filesystem, SDK, command-line tool, or other system. S121

The three labels describe architectural roles, not necessarily three separate products or machines. When MCP functionality is configured, Claude Desktop, ChatGPT, VS Code, Cursor IDE or CLI, Gemini CLI, Zed, and JetBrains AI Assistant can act as host surfaces containing MCP client implementations. Scope matters: a product name alone does not prove that MCP is enabled, which transports or primitives are available, or that every surface behaves the same way. A product can also bundle another role: Claude Code can separately expose itself as an MCP server, and JetBrains offers an AI Assistant client feature and an integrated IDE server feature. S259 S140 S141 S144 S274 S275

The model does not ordinarily open an MCP connection by itself. The host decides which server capabilities to reveal to the model, translates between provider-specific tool formats and MCP where necessary, asks for user confirmation, invokes the client, and decides how to use the result. A server does not automatically see the full conversation; it receives only the arguments, context, credentials, and metadata the host/client sends. S121 S123

Current MCP is also different from the architecture described in many 2024–2025 tutorials. Revisions through 2025-11-25 used an initialize handshake, capability negotiation, an initialized notification, and protocol-session semantics. Revision 2026-07-28 removed that handshake and Mcp-Session-Id. Modern requests carry their protocol version and relevant client capabilities, while server/discover can be used to learn a server’s supported versions and capabilities before another operation. The host–client–server separation survived; the hidden session state did not. S055 S056 S127

---

The architecture in one diagram

                                      ┌─ MCP Client A ─ MCP Server A ─ Filesystem
User ─ User interface ─ Model ─ Host ─┼─ MCP Client B ─ MCP Server B ─ GitHub API
                                      ├─ MCP Client C ─ MCP Server C ─ Database
                                      └─ MCP Client D ─ MCP Server D ─ SaaS service

The diagram makes four relationships visible:

1. The host is positioned between the user/model experience and every MCP server.
2. The host may create and coordinate multiple MCP clients.
3. Each client maintains an isolated logical relationship with one server.
4. Each server remains focused on its own capabilities and underlying systems.

That isolation is deliberate. The current architecture says the host should preserve security boundaries between servers, retain the full conversation, control cross-server interactions, and decide what context each server receives. A server should not be able to inspect the host’s entire conversation or the capabilities of peer servers unless the host explicitly sends that information. S121

The architecture is therefore not:

Model ─ directly calls every MCP server

It is closer to:

Model produces intent
        ↓
Host interprets and authorizes that intent
        ↓
MCP client sends a protocol request
        ↓
MCP server performs or delegates the operation
        ↓
Host receives, validates and presents the result

This distinction explains why two hosts can connect to the same server yet behave differently. The server supplies capabilities; the host determines the model, context, tool-selection process, confirmation UI, supported extensions, error policy, and result rendering.

---

MCP roles are logical roles, not product categories

Software documentation often uses nouns at several abstraction levels at once. “Client” may refer to a library object, a connection, a desktop application, a cloud service, or an entire product. MCP becomes easier to reason about when these are separated.

Protocol role

A protocol role defines which side sends and receives particular MCP messages.

• The client sends methods such as server/discover, tools/list, tools/call, resources/list, resources/read, prompts/list, and prompts/get.
• The server returns results, errors, subscribed notifications, and—under the current architecture—input_required results when more user or host input is needed.
• Both sides use JSON-RPC 2.0 message structures, but MCP defines the methods, schemas, capabilities, version rules, and transport conventions layered on top. S127 S130 S123 S001

Application role

The host is an application-level role. It coordinates the user interface, model loop, multiple clients, credentials, permissions, and context. MCP does not standardize every host behavior. Two products can be equally protocol-compatible while presenting radically different user experiences.

Implementation

An implementation is the code realizing a role. An official TypeScript SDK supplies classes for implementing clients and servers, but the SDK package is not itself a running client or server. Only an instantiated component participating in the protocol has that role. S252 S167 S256 S257

Process and service

A process is an operating-system execution unit. A local server is often one subprocess, but a remote logical server may consist of many replicas behind a load balancer. Conversely, a single product process can bundle a host, several clients, and even a server.

Package and configuration

A server package is distributed software. A host-specific JSON entry tells a product how to find or launch a server. Neither the package listing nor the configuration object is the protocol role itself.

These distinctions prevent several common category errors:

SDK ≠ instantiated client
configuration ≠ client
package ≠ running server
endpoint ≠ server process
host product ≠ one client connection
logical server ≠ one container

---

Host, client, and server roles

What is an MCP host?

An MCP host is the application or service that gives the protocol a user-facing and model-facing purpose. The current specification describes the host as the container and coordinator that creates and manages clients, controls connection permissions and lifecycle, enforces security and consent, handles user authorization decisions, integrates with the AI model, aggregates context, and manages coordination across servers. S121

A host can be:

• a desktop AI application;
• an IDE or coding-agent interface;
• a web application;
• a command-line agent;
• a custom application built with an SDK;
• a cloud API feature that coordinates model and MCP operations;
• an enterprise agent platform or gateway-backed application.

The role is defined by responsibilities rather than branding.

The host owns the user experience

The protocol can describe a tool and carry a tool call, but it does not define one universal confirmation dialog. The host decides whether to:

• show every call;
• automatically approve read-only operations;
• block destructive operations;
• apply an organization allowlist;
• show tool arguments before execution;
• require a second approval after arguments change;
• expose a server’s prompts as slash commands;
• render structured results as a table;
• launch an MCP App in a sandbox;
• hide unsupported capabilities.

This is why “the MCP server asked the user for permission” is usually imprecise. The server can return an authorization challenge, an input_required result, or metadata relevant to an operation. The host owns the interface through which the user sees and responds to that need. S123 S126

The host owns the model loop

MCP is not an LLM and does not mandate a model provider. The host decides:

• which model receives the user’s request;
• which tool definitions are shown to that model;
• how tool schemas are translated into the provider’s format;
• whether resources enter the context window;
• whether a prompt template is offered to the user;
• how many tool-result/model rounds are allowed;
• how errors are summarized;
• when the agent loop terminates.

Microsoft’s description of an agent harness closely matches these host duties: assemble context, invoke a model, interpret structured tool calls, execute or route tools, return results, and repeat. MCP can supply the external capabilities used by that harness, but MCP does not replace the harness. S264

The host owns cross-server orchestration

Suppose a user asks:

Read the production incident in Slack, inspect the related GitHub pull request, query the observability database, and create a follow-up issue.

A host might use four servers:

Slack server       → messages and threads
GitHub server      → repository and issue tools
Database server    → telemetry query
Project server     → issue creation

Each client-server relationship remains isolated. The host is the component that can combine outputs, decide whether one server’s result should be sent to another, and maintain the overall plan. That design limits what a compromised server can learn by default.

The host owns the complete conversation

The current architecture explicitly places full conversation retention in the host. Servers receive only necessary context. This is both a privacy boundary and a practical design rule. S121

A tool call may contain:

{
  "name": "create_issue",
  "arguments": {
    "repository": "example/project",
    "title": "Investigate timeout regression",
    "body": "Summary derived by the host..."
  }
}

The GitHub server does not need every earlier user message, every output from the database server, or the model’s hidden reasoning. The host can send a concise body assembled from those sources.

Host responsibilities are not fully standardized

The protocol standardizes the wire boundary, not the entire product. It does not force every host to support:

• every server capability;
• every client-side capability;
• every extension;
• identical permission prompts;
• identical context limits;
• identical schema conversion;
• identical server installation methods;
• identical OAuth behavior;
• identical error recovery.

This is why interoperability is real but bounded.

---

What is an MCP client?

An MCP client is the protocol-speaking component created by a host for a particular server. The current architecture describes each client as communicating with exactly one server, attaching protocol version and client capabilities to every request, routing messages, managing subscriptions and notifications, and maintaining isolation from other servers. S121

The client is not necessarily visible to the user. It may be:

• an object inside a desktop application;
• a service inside a cloud product;
• a library object in a developer’s process;
• an internal component that launches a local subprocess;
• a hosted connector operated by a model provider;
• an adapter behind an enterprise gateway.

A client handles protocol mechanics

Typical client-side work includes:

1. Locating or launching the server.
2. Selecting stdio or Streamable HTTP.
3. Constructing valid JSON-RPC requests.
4. Adding current protocol metadata.
5. Optionally calling server/discover.
6. Listing tools, resources or prompts.
7. Parsing server results and errors.
8. Managing subscribed notification streams.
9. Retrying according to operation and transport semantics.
10. Reporting results to the host.

An SDK can hide much of this work. The role remains the same even when a developer uses one high-level method.

A current client carries version and capabilities per request

Under 2026-07-28, modern requests are self-describing. The client carries:

• the protocol version;
• client implementation information;
• client capabilities relevant to the request.

The server validates the version and can return an unsupported-version error. The client may call server/discover first to obtain supported versions, server identity metadata and capabilities. server/discover is required for current servers but optional for clients; a client can attempt a request directly and handle a version error. S056 S127

This replaces the old model:

Open connection
   ↓
initialize
   ↓
negotiate version and capabilities
   ↓
initialized notification
   ↓
use session state for later messages

with a model closer to:

Optional server/discover
   ↓
Send a self-describing request
   ↓
Receive an independent response

One client to one server is a logical relationship

The phrase “one client connects to one server” remains useful, but it must be interpreted carefully.

It does not mean:

• one host can use only one server;
• one client equals one TCP connection;
• one client requires one persistent protocol session;
• one server equals one process;
• one remote server can serve only one client;
• each request must reach the same replica.

It means that an MCP client instance or logical client relationship is scoped to one server. That supports:

• capability isolation;
• server-specific credentials;
• server-specific errors and retries;
• independent transport configuration;
• permission and tool-name scoping;
• easier revocation;
• reduced cross-server leakage.

A host with ten servers generally has ten logical client relationships, even if its networking stack pools HTTP connections or a gateway multiplexes traffic.

The client does not own the complete application policy

A low-level client library may expose hooks for approval, authorization or validation. The host still determines the policy. The client cannot know by itself:

• whether the user intended a destructive operation;
• whether two server results may be combined;
• which model should receive a tool schema;
• whether a tool should be hidden due to enterprise policy;
• how a result should be rendered;
• when the agent should stop.

Those are host decisions.

The client can exist without an LLM

A program can invoke MCP methods directly:

Scheduled process
   ↓
MCP client
   ↓
resources/read
   ↓
Store result in an index

No model is required. The client/server protocol remains valid because MCP is an application integration protocol, not a model execution engine. The “model” in Model Context Protocol describes the target ecosystem and use case, not a mandatory wire participant.

---

What is an MCP server?

An MCP server is a program or network service implementing the server side of MCP. It exposes a focused set of capabilities to compatible clients. Those capabilities may include tools, resources, prompts, or extensions. S121 S123 S124 S125

A server can wrap:

• a REST or GraphQL API;
• a relational or vector database;
• a local filesystem;
• a Git repository;
• an IDE;
• a command-line program;
• a SaaS platform;
• a search engine;
• a proprietary SDK;
• a long-running workflow system;
• local application functionality.

MCP does not prescribe the backend.

The server publishes capabilities

The server controls what it exposes. For tools, it supplies names, descriptions and input schemas, and may supply output schemas and annotations. For resources, it exposes URI-addressed data and templates. For prompts, it exposes templates a host may surface to a user. S123 S124 S125

The client discovers these definitions; the host decides which to use.

The server executes or delegates operations

When a client sends tools/call, the server:

1. authenticates and authorizes the request as required;
2. validates the arguments;
3. maps the call to local code or an underlying system;
4. handles backend errors;
5. returns an MCP result.

The client transports the request. The server owns the operation’s implementation and should enforce business authorization rather than assuming the host’s confirmation is enough.

The server is not automatically an agent

A server may expose one simple deterministic tool:

convert_temperature(celsius) → fahrenheit

It may expose a complex long-running research workflow. It may internally use an LLM. None of those facts changes its protocol role.

An agent is usually an application loop that plans, selects actions, interprets results and continues until a goal or stopping condition. An MCP server can be used by an agent or expose agentic work, but “server” and “agent” are not synonyms.

The server does not own the host’s model

Launch-era MCP included server-initiated sampling so a server could ask the client/host to perform model inference without the server holding model credentials. Current MCP deprecates the older sampling primitive and moves interactive needs into newer patterns and extensions, but the underlying architectural principle remains: model execution belongs under host/client control unless an application explicitly delegates otherwise. S055 S126

A logical server may be many replicas

Current remote MCP is designed to work behind ordinary HTTP infrastructure:

MCP client
    ↓
Gateway / load balancer
    ├─ Server replica 1
    ├─ Server replica 2
    └─ Server replica 3

Because the protocol core no longer depends on a hidden session, successive requests can reach different instances. Application state can remain in a database or be represented by explicit, authorized handles. S055 S123 S058 S061

---

Host, client and server compared

The MCP server cornerstone goes deeper on server implementation, examples, installation, and deployment.

Host, client and server compared comparison table

Question	Host	Client	Server
What is it?	User/model-facing coordinator	Protocol component for one server	Capability provider
Does it own the UI?	Yes	No independent requirement	Usually no
Does it own the model loop?	Yes	No	No protocol requirement
Can it coordinate several servers?	Yes	No	No
Does it construct MCP requests?	Through its client subsystem	Yes	Receives them
Does it publish tools/resources/prompts?	Curates them	Discovers them	Yes
Does it execute tools/call effects?	Approves/routes	Sends	Executes/delegates
Does it keep the full conversation?	Yes	Only necessary protocol state	Only receives what is sent
Does it choose confirmation policy?	Yes	Implements mechanics	May enforce additional authorization
Does it validate backend permissions?	May precheck	Carries identity	Must enforce or preserve them
Can it be local or remote?	Yes	Yes	Yes
Is it an LLM?	No, but integrates one	No	No
Is it automatically an agent?	May contain an agent loop	No	No
How many?	One host may manage many clients	One logical server per client	One server may serve many clients

The complete research package includes a thirty-row responsibility matrix because many important duties—credential storage, tenant isolation, notification subscriptions, MCP Apps, explicit state handles, and observability—cannot be represented in a small table.

---

Where does the LLM sit?

The MCP vs function calling comparison follows the translation between provider-native model tool calls and MCP methods.

The model normally sits behind or inside the host’s model integration layer:

User
  ↓
Host UI and agent loop
  ↔ Model provider / local model
  ↓
MCP client
  ↓
MCP server

The model may produce a structured tool call, but the host interprets that output. The host may map an MCP tool definition into OpenAI, Anthropic, Gemini, or another model provider’s native tool format. After the model selects a tool, the host invokes tools/call through the appropriate MCP client. S123 S090 S264

This produces a layered sequence:

1. MCP client discovers `create_issue`.
2. Host filters and converts its schema.
3. Host presents the tool to the model.
4. Model returns a provider-specific tool call.
5. Host checks policy and asks for confirmation if required.
6. Client sends MCP `tools/call`.
7. Server invokes the source-control API.
8. Client receives the MCP result.
9. Host converts the result for the model and user.

The model does not need to know whether the capability came from:

• a direct application function;
• an MCP server;
• a provider-hosted tool;
• an internal service;
• a gateway-generated adapter.

The host owns that abstraction.

Can a server call a model?

A server implementation can call any API its operator permits, including a model API. That is an implementation choice, not a built-in identity. Historically, MCP also gave servers a protocol mechanism to request sampling through the client. Current architecture changes and deprecations mean that any statement about server-to-client sampling must name the specification revision. S249 S251 S055

Can MCP work without a model?

Yes. A client can programmatically list tools, read resources, invoke tools, or monitor subscribed notifications. The protocol is useful as a structured application boundary even when deterministic software—not an LLM—chooses every method.

---

Architecture by protocol era

The launch-era architecture: 2024–2025

Use the primary-source MCP history to place each architecture claim in its released protocol era.

The host–client–server roles were present in the first public specification. The early architecture described:

• hosts as LLM applications;
• clients as connectors within hosts;
• servers as services providing context and capabilities;
• one stateful client/server session;
• version and capability negotiation during initialization;
• bidirectional JSON-RPC requests;
• stdio and HTTP+SSE transports. S249 S026 S250

The lifecycle was central:

Client connects
   ↓
Client sends initialize
   ↓
Server selects protocol version and returns capabilities
   ↓
Client sends notifications/initialized
   ↓
Normal operation begins

The connection carried negotiated state. A server could know what the client had declared during initialization. Later messages did not need to repeat all of that data.

Why old documentation calls the client a session manager

That wording was accurate for the legacy era. The 2025 architecture said each client maintained a stateful session with one server. Streamable HTTP replaced the original two-endpoint HTTP+SSE transport in March 2025, but the new transport initially kept initialization and optional session identifiers. S156 S251 S036

The protocol changed in layers:

November 2024

• stateful initialization;
• stdio and HTTP+SSE;
• tools, resources and prompts;
• direct server-to-client requests such as sampling.

March 2025

• Streamable HTTP;
• OAuth authorization framework;
• still initialized and stateful;
• direct server-to-client requests retained.

June 2025

• structured tool output;
• elicitation;
• authorization hardening;
• still initialized and stateful.

November 2025

• expanded authorization and elicitation;
• experimental Tasks;
• last released handshake/session architecture.

A page written in 2025 is not necessarily “wrong” when it says clients negotiate capabilities during initialize. It becomes wrong when that description is silently presented as the only current architecture after July 28, 2026.

---

The current architecture: 2026-07-28

The 2026-07-28 release guide and stateful-to-stateless migration guide cover the current wire rules and compatibility boundary.

The 2026-07-28 revision made the largest architectural change since launch. It removed:

• initialize;
• notifications/initialized;
• protocol-level sessions;
• Mcp-Session-Id;
• the assumption that future requests must reach a process holding negotiated state. S055 S058

It added or formalized:

• version and client capabilities on every request;
• server/discover;
• explicit result types;
• Multi Round-Trip Requests;
• header-based routing;
• cacheable list results;
• explicit subscription streams;
• an extensions framework. S055 S127

Current request flow

A modern client can begin with discovery:

Client → server/discover
Server → supported versions, capabilities, identity metadata

It then sends a request containing current metadata:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "_meta": {
      "protocolVersion": "2026-07-28",
      "clientInfo": {
        "name": "example-host",
        "version": "1.0.0"
      },
      "clientCapabilities": {}
    }
  }
}

The exact schema should be taken from the released specification, not copied from this simplified teaching example. The architectural point is that the request carries the information the server needs rather than depending on an earlier handshake. S056 S127

server/discover does not create a session

Discovery reports what the server says it supports. It does not establish hidden connection state. A later request is still self-describing.

The server’s identity metadata is also self-reported; it is useful for user interfaces and diagnostics but should not be treated as a cryptographic publisher certificate. S127

MRTR replaces ordinary server-initiated requests

Earlier MCP allowed the server to send a JSON-RPC request back to the client during an active session. That pattern was difficult to route through stateless HTTP infrastructure.

Current Multi Round-Trip Requests use a result such as input_required. The client/host obtains the needed input, then retries the outer request with explicit request state and input responses. S055 S123 S126

Conceptually:

Client → tools/call
Server → input_required: ask user for project ID
Host   → shows elicitation UI
Client → retries tools/call with project ID and request state
Server → complete result

The host remains in control of the user interaction. The server remains in control of its operation. The client transports the rounds.

Stateless does not mean memoryless

A server can maintain:

• durable database records;
• a background job;
• a Task;
• authorization state;
• a cache;
• an external workflow;
• an explicit server-generated handle.

The current tools specification describes the explicit-handle pattern. The server returns a handle, and the host/model includes it in later calls. The server must bind that handle to the correct user and authorization context. S123

The difference is:

Legacy: hidden state associated with protocol session
Current: explicit request data or application-managed durable state

---

Did the 2026 revision eliminate the client–server relationship?

No.

Stateless protocols still have clients and servers. HTTP itself is the clearest example. A client sends a request; a server processes it. Removing a handshake changes how the parties establish compatibility and carry state, not which party initiates an MCP method or exposes a capability.

Current MCP still defines:

• client requests;
• server responses;
• client capabilities;
• server capabilities;
• client-side features;
• server-side primitives;
• one client’s logical relationship to a particular server;
• host management of multiple clients. S121 S130

The revision eliminated a protocol session, not the client role.

---

Does one MCP client still connect to one server?

The current architecture still describes a one-to-one client/server relationship. The correct interpretation is logical, not necessarily physical. S121

Logical relationship

The client keeps one server’s:

• endpoint or process configuration;
• capabilities;
• identity metadata;
• credentials;
• tool/resource/prompt namespace;
• errors and retry context;
• notification subscriptions.

Physical deployment

The same logical server might be:

one local subprocess

or:

one URL → gateway → many replicas

The client’s HTTP stack might:

• open a fresh connection;
• reuse a keep-alive connection;
• multiplex requests over HTTP/2;
• route through a corporate proxy;
• receive an SSE response stream for one request.

None of those transport details changes the logical role.

Why maintain one client per server?

Isolation reduces accidental coupling. If two servers expose a tool named search, the host can scope names by server. If one server is revoked, its client relationship can be closed without affecting others. Credentials stay server-specific. A malformed response is attributed to one boundary.

The current tool specification recognizes that name collisions are possible across servers and leaves disambiguation to clients, proxies, or hosts. S123

---

Local, remote, and multi-server topology

Local MCP architecture

The MCP transport guide compares stdio, current Streamable HTTP, and the two legacy HTTP eras.

The most familiar local pattern is:

Host application
    ↓ creates client
Client launches subprocess
    ↓ writes JSON-RPC to stdin
Local MCP server
    ↓ writes JSON-RPC to stdout
Client returns result to host

The current stdio specification says the client launches the server as a subprocess, writes messages to stdin, reads messages from stdout, and treats stderr separately for logging. Messages are newline-delimited JSON-RPC. S132

What the host does locally

The host determines:

• which configuration is trusted;
• what command and arguments may run;
• what directories the server can access;
• which environment variables are inherited;
• whether packages may be downloaded automatically;
• whether a project may define server configuration;
• whether the process runs in a sandbox;
• which tools are exposed to the model.

Zed’s current worktree-trust rules illustrate that this is a host security responsibility: Restricted Mode prevents project-configured language and MCP servers from being downloaded or started until the worktree is trusted. Globally configured servers are outside that worktree-trust gate. S272

What the client does locally

The client:

• starts the exact process;
• maintains stdin/stdout framing;
• separates logs from protocol output;
• detects process exit;
• terminates or restarts according to host policy;
• reports startup failures;
• sends modern or legacy protocol messages according to compatibility mode.

What the server does locally

The server:

• runs with the permissions of its process identity;
• validates paths and commands;
• constrains filesystem roots;
• avoids writing logs to stdout;
• returns protocol errors rather than crashing where possible;
• protects local secrets and external credentials.

Local does not mean harmless. A local server package is executable code.

---

Remote MCP architecture

A current remote deployment may look like:

Host
  ↓
MCP client
  ↓ HTTPS
Enterprise gateway / load balancer
  ↓
Logical MCP server
  ├─ Replica A
  ├─ Replica B
  └─ Replica C
       ↓
SaaS API / database / internal service

The client sends each MCP request to the Streamable HTTP endpoint. The server may return an ordinary JSON result or a request-scoped SSE stream. Current MCP removed the old general GET stream and protocol sessions. S131

The host’s remote responsibilities

The host manages:

• approved endpoint policy;
• account connection and consent;
• credential storage;
• user-facing server identity;
• tool allowlists;
• confirmation policy;
• organization restrictions;
• context sent off-device;
• result handling.

The client’s remote responsibilities

The client manages:

• HTTP request formation;
• protocol metadata;
• authorization flow mechanics;
• TLS and redirect behavior through its HTTP stack;
• streaming response handling;
• retry and timeout behavior;
• server discovery and version errors;
• subscribed notification streams.

The server’s remote responsibilities

The server manages:

• token validation;
• user and tenant authorization;
• resource ownership;
• rate limits;
• backend credentials;
• horizontal scaling;
• observability;
• safe explicit state handles;
• cache scope;
• errors that do not leak sensitive information.

A gateway is not a fourth core MCP role

Gateways, reverse proxies, aggregators and policy layers are ecosystem deployment roles. A gateway may terminate authorization, route requests, rewrite names, combine catalogs, or enforce policy. The core protocol still sees client and server behavior on each side of that intermediary.

Marketing terms should not be projected into the specification. “MCP gateway” is useful operational vocabulary, but it is not equivalent to host, client or server.

---

One host using multiple servers

Consider a coding host with three servers:

Host
 ├─ Client: filesystem
 ├─ Client: GitHub
 └─ Client: database

At startup or discovery time, the host obtains:

filesystem:
  read_file
  write_file

GitHub:
  search_code
  create_issue

database:
  list_tables
  query_readonly

The host may:

1. Prefix or group names to avoid collisions.
2. Hide write_file in read-only mode.
3. expose query_readonly only for approved projects;
4. defer loading rarely used tool schemas;
5. show only five tools to the model for a particular request;
6. require confirmation for create_issue;
7. keep database results out of the GitHub server unless required.

The client objects do not jointly plan this. The host does.

Cross-server trust

A compromised database server might return text instructing the model to call write_file with sensitive data. The host is the only component positioned to recognize that the returned content is untrusted, apply prompt-injection defenses, restrict cross-server actions, and require confirmation.

Server isolation reduces exposure, but the host’s model loop can still create cross-server effects. Architecture and security are inseparable here.

---

The same server used by different hosts

Suppose the same GitHub MCP server is configured in:

• Claude Code;
• ChatGPT;
• VS Code;
• Cursor;
• Gemini CLI.

Protocol compatibility may allow all five to list and call tools. Their behavior can still differ.

The same server used by different hosts comparison table

Host behavior	Possible differences
Model	Different providers, versions and tool-selection quality
Tool catalog	Full list, filtered list, lazy loading or search
Naming	Original names or server-prefixed names
Confirmation	Every call, destructive calls only, policy-based, or autonomous
Resources/prompts	Supported, partially supported or ignored
Apps/extensions	Supported only in selected hosts
Authorization	Browser OAuth, enterprise-managed flow, static token or unsupported
Context	Different conversation, repository and workspace data
Error recovery	Retry, model-visible error, user prompt or immediate failure
Rendering	Plain text, structured cards, IDE edits or sandboxed UI
Legacy support	Modern only, dual-era, or product-specific compatibility

Wire compatibility guarantees neither identical user experience nor identical security posture.

---

Current product role classification

The maintained host compatibility matrix tracks documented product behavior separately from these durable role definitions.

Product names often conceal bundled roles. The following classifications were rechecked against current first-party documentation on August 25, 2026. They remain live-check required because product surfaces, plans, transports, and names can change independently of the protocol.

Anthropic

Claude Desktop

When MCP functionality is configured, Claude Desktop is a host containing MCP clients. Desktop extensions connect to local, on-device MCP servers; remote connectors use Anthropic-managed cloud connection infrastructure. Those are distinct mechanisms. No general MCP server role is documented for the Claude Desktop surface. S258 S260 S145

Claude Code

Claude Code is a host and client when it uses external servers. Current documentation covers local stdio plus remote Streamable HTTP, deprecated SSE, and WebSocket connections. The separate claude mcp serve command can expose Claude Code capabilities as an MCP server to another client, so one product implements different roles in different relationships. S259

Claude remote connectors

When a remote connector is enabled, the Claude surface—web, mobile, Cowork, Desktop, or Claude Code—is the user-facing host, while the MCP connection originates from Anthropic cloud infrastructure. Local Claude Desktop extensions remain a separate on-device mechanism. S258 S145

Messages API MCP connector

For the beta Messages API connector, the developer application remains the application-level orchestrator. Anthropic’s managed connector uses tools from public HTTPS remote MCP servers over Streamable HTTP or legacy SSE. It does not directly support local stdio, MCP prompts, or MCP resources, and the connector is not itself the connected server. S175

OpenAI

ChatGPT

When an MCP app is enabled in a supported ChatGPT web product mode, ChatGPT is the user/model host and OpenAI-managed infrastructure performs remote MCP client behavior. Full write or modify MCP is beta for Business, Enterprise, and Edu; Pro developer mode supports read and fetch. ChatGPT does not connect directly to local MCP servers; supported private, on-premises, or developer-machine servers use Secure MCP Tunnel. ChatGPT is not the connected MCP server. S140 S262

OpenAI Agents SDK

In an OpenAI Agents SDK application, the developer’s running application is the host. HostedMCPTool or SDK MCP connection classes provide client behavior, and MCPServerManager can coordinate several configured servers. The cited MCP integration documents no built-in MCP server role; an application may implement one separately. S090

Microsoft and GitHub

VS Code

In MCP role terminology, VS Code’s agent experience is a host containing clients for configured local and remote servers. Current documentation covers tools, resources, prompts, and MCP Apps alongside product-specific trust, sandbox, and enterprise policy. Microsoft’s separately named Agent Host is an AHP runtime or process; an MCP relationship can run in the extension host or Agent Host without changing VS Code’s MCP host role. S141 S088

GitHub Copilot cloud agent

GitHub Copilot cloud agent—formerly Copilot coding agent—is the hosted host/orchestrator when MCP is configured and uses MCP client behavior for configured servers. Cloud agent and code review support MCP tools but not resources or prompts; remote OAuth servers are unsupported, and configured tools may run without per-call approval. Those are product limits, not universal protocol limits. S265 S266

Copilot Chat and CLI

Each is a host with client functionality. A preconfigured GitHub MCP server is a distinct server component, even when the user experiences it as part of one product. S267 S268

Google

Gemini CLI is a command-line host and MCP client. Official codelabs show it configuring local and remote servers, requesting permission before tool use, and connecting to Google-hosted MCP services. S144 S271

Cursor

Cursor IDE/Agent Window and Cursor CLI are distinct MCP host surfaces that share configuration and consume configured servers. Neither surface is thereby the configured server, and this classification does not generalize to Cursor Cloud Agents. S269

Zed

Zed is a host and client platform. Current MCP documentation, worktree trust, and mcp:<server>:<tool> permissions show host responsibilities clearly. Restricted Mode gates project-configured language and MCP servers until worktree trust; globally configured servers are outside that gate. Per-tool allow, deny, and confirm rules remain host policy. S272 S273 S284 S285

JetBrains

JetBrains illustrates why roles must be classified by enabled component:

• AI Assistant, when its MCP integration is enabled, acts as a host/client connecting to external servers.
• The separate IDE MCP Server exposes IDE tools to external clients and can supply SSE, stdio, or HTTP Stream configuration.
• The host can pass configured MCP tools to several integrated agents. S274 S275 S276 S277

When AI Assistant and the integrated MCP Server are enabled, the suite can consume MCP servers and separately expose IDE tools without collapsing the roles.

---

Capabilities, primitives, and permissions

Capability negotiation: legacy and current

“Capability negotiation” means different things in different revisions.

Legacy negotiation

During initialize, the client and server exchanged:

• protocol version;
• client capabilities;
• server capabilities;
• implementation information.

The selected state applied to the session. S026 S156 S160

Current per-request capabilities

Modern requests carry client capabilities relevant to the request. The server uses those declarations to decide what behavior is permitted. The client can use server/discover to inspect server support first. S121 S056 S127

This is not merely a field relocation. It changes infrastructure properties:

• no sticky routing required by MCP core;
• no session store required for negotiated capabilities;
• requests can be inspected independently;
• gateways can route using request metadata;
• horizontal scaling is simpler;
• capability changes can be represented per request.

Capability declaration is not implementation proof

A client declaring a capability says it supports the corresponding behavior. A server describing a capability says it exposes that behavior. Bugs, partial support and product restrictions can still exist.

Interoperability testing must exercise behavior, not merely inspect declarations.

---

Tools, resources and prompts by role

Tools

Server:

• lists tool definitions;
• validates and executes calls;
• returns results.

Client:

• requests the list;
• invokes a named tool;
• transports results and errors.

Host:

• decides which tools are visible;
• converts schemas for the model;
• obtains confirmation;
• interprets results.

Model:

• may select a tool through provider-specific function calling.

Resources

Server:

• publishes URI-addressed resources and templates;
• reads resource contents;
• emits subscribed changes where supported.

Client:

• lists and reads resources;
• maintains subscriptions.

Host:

• decides whether and how resource content enters context;
• labels provenance;
• applies size and trust controls;
• renders attachments or references.

A tool result is not automatically a resource.

Prompts

Server:

• publishes named prompt templates and arguments.

Client:

• lists and retrieves them.

Host:

• surfaces them as commands, forms or templates;
• chooses whether they become user messages, context or workflow inputs.

An MCP prompt is not the host’s system prompt.

---

Permissions and responsibility boundaries

The MCP security guide expands these role boundaries into a layered threat model and operational controls.

The host’s confirmation and the server’s authorization answer different questions.

Host confirmation

Does the user intend for this model-driven application to attempt this action now?

Server authorization

Is this caller allowed to perform this action on this object under current credentials and policy?

Both may be required.

A user can confirm “delete file,” but the server must still reject a path outside its approved root. A host can approve “create issue,” but the server or GitHub API must still reject a repository the user cannot access.

Tool annotations are not permissions

MCP tool annotations can describe properties such as read-only or destructive. The specification says clients must treat annotations as untrusted unless the server itself is trusted. They help a host design policy; they do not enforce the effect. S123

The host cannot outsource semantic safety to JSON Schema

Schema validation can prove that path is a string. It cannot prove that the path is inside an authorized directory. It can prove that amount is a number. It cannot prove that a payment is legitimate.

Server-side semantic and business authorization remains essential.

---

MCP without an LLM

A deterministic program can use MCP as a reusable integration layer.

Example:

Nightly indexer
  ↓
MCP client A → documentation server → resources/list + resources/read
  ↓
MCP client B → GitHub server → search tool
  ↓
Index database

The program—not a model—chooses every method. This demonstrates:

• the host can be a service rather than a chat application;
• MCP clients are ordinary protocol components;
• tools can be called programmatically;
• the “model” is not a wire-level participant.

MCP’s strongest adoption story may remain AI applications, but its architecture is not technically limited to stochastic model selection.

---

Debugging MCP by responsibility

When an integration fails, start with the role boundary.

Host symptoms

• Tool never appears to the model.
• Confirmation UI is wrong.
• Result is rendered poorly.
• Cross-server context leaks.
• Product ignores prompts or resources.
• Unsupported extension is silently dropped.

Investigate:

• host filters and policy;
• model tool limits;
• schema translation;
• user/workspace settings;
• extension support;
• context construction.

Client symptoms

• Server cannot be launched.
• JSON-RPC framing is invalid.
• Version mismatch occurs.
• HTTP authorization never completes.
• SSE response is parsed incorrectly.
• Subscription drops.
• Retry duplicates an effect.

Investigate:

• transport;
• protocol metadata;
• compatibility mode;
• SDK version;
• timeout and retry behavior;
• credential configuration;
• stdout contamination.

Server symptoms

• Tool list is wrong.
• Call arguments pass schema validation but cause unsafe effects.
• Authorization is bypassed.
• Wrong tenant data appears.
• Explicit handle can be guessed or reused.
• Backend error leaks secrets.
• Tool description is inaccurate.

Investigate:

• server implementation;
• backend mapping;
• semantic validation;
• token binding;
• tenant context;
• state-handle design;
• error sanitization.

Underlying-system symptoms

• Native API rejects the operation.
• Database permission differs from host expectation.
• Rate limit is exceeded.
• Eventual consistency delays results.
• Service account is overprivileged.

MCP does not erase the backend’s own behavior.

---

Mistakes, recommendations, and myths

Common architecture mistakes

“The MCP server contains the model”

No. A server may use a model internally, but MCP does not require that. The model normally runs through the host.

“The MCP client is always the app users open”

The app is usually the host. It contains multiple clients.

“One client connects to every server”

The host manages one logical client relationship per server.

“The model calls the server directly”

The host mediates model output, permissions and client invocation.

“The server sees the entire conversation”

Only if the host sends it. Server isolation and minimal context are architectural principles.

“The server decides which tool the model uses”

The server publishes tools. The host/model selects among the exposed subset.

“The client executes the tool”

The client sends the call. The server executes or delegates it.

“MCP still requires initialization”

Only legacy revisions through 2025-11-25 do. Current 2026-07-28 does not.

“Stateless MCP cannot support workflows”

Application state, explicit handles, Tasks and backend records remain possible.

“Remote MCP always means a persistent SSE stream”

Current Streamable HTTP can return JSON or request-scoped SSE; the old GET stream and protocol session were removed. S131

“Compatible hosts behave identically”

They share a protocol boundary, not a universal product design.

---

Architecture design recommendations

For host developers

1. Treat the host as the primary security and orchestration boundary.
2. Create separate client contexts for separate servers.
3. Expose only relevant tools to the model.
4. Preserve server provenance in every result.
5. Require explicit policy for cross-server actions.
6. Keep the full conversation out of servers by default.
7. Distinguish model tool calls from MCP calls in logs.
8. Support modern and legacy eras deliberately rather than accidentally.
9. Show server identity, account and action scope to users.
10. Record confirmation, arguments, result and backend effect where possible.

For client/SDK developers

1. Keep transport semantics separate from MCP method semantics.
2. Attach current version and capabilities correctly.
3. Implement server/discover and unsupported-version recovery.
4. Avoid treating self-reported server metadata as verified identity.
5. Scope credentials and caches to the server and authorization context.
6. Make retries safe and visible.
7. Preserve structured results without silently discarding content types.
8. Provide clean cancellation and timeout behavior.
9. Keep one server’s notifications and errors isolated from another.
10. Offer explicit modern/legacy compatibility modes.

For server developers

1. Expose a focused, coherent capability surface.
2. Validate semantics, not merely JSON shape.
3. Preserve native backend authorization.
4. Bind explicit handles to user, tenant and scope.
5. Do not assume the host displays annotations or confirmations.
6. Minimize required context.
7. Return structured, provenance-preserving results.
8. Avoid hidden model instructions in metadata or content.
9. Design for independent HTTP requests when supporting current MCP.
10. Document versions, transports, authentication and optional capabilities precisely.

For enterprise architects

1. Inventory host, client, gateway and server roles separately.
2. Approve server publishers and endpoints, not just tool names.
3. Define which hosts may use which servers.
4. Keep user identity and tenant context end to end.
5. Collect logs at host, gateway, server and backend layers.
6. Test actual interoperability per product and version.
7. Do not assume a gateway repairs unsafe business logic.
8. Maintain a compatibility matrix for current and legacy revisions.

---

Myths versus evidence

Myths versus evidence comparison table

Myth	Evidence-based correction
MCP has only clients and servers	The specification also defines the host application role.
Host and client are synonyms	The host manages multiple clients and owns model/UI policy.
Every “MCP client” product is only a client	Products commonly bundle host and client roles.
One client means one network connection	It means one logical server relationship.
One server means one process	A remote server may be horizontally replicated.
The model is part of MCP	MCP can operate without an LLM.
The model connects directly to servers	The host mediates the model and MCP clients.
Servers see all chat context	The host controls what each server receives.
Servers choose model tools	Servers publish capabilities; hosts/models select them.
Clients execute tools	Servers execute or delegate operations.
MCP always initializes a session	The current specification removed initialization and sessions.
Stateless means no application state	Explicit handles and durable state remain possible.
server/discover authenticates a server	Identity metadata is self-reported and not sufficient proof.
Tool annotations enforce safety	They are descriptive hints, not enforcement.
Protocol compatibility means identical UX	Host support and policy differ.
An SDK package is a client	It supplies code used to instantiate one.
A connector is always a server	Connector is product terminology with several possible mappings.
MCP Apps turn servers into hosts	Hosts still render, sandbox and mediate the server-provided UI.
Remote MCP requires an always-open SSE channel	Current Streamable HTTP uses independent POST requests and optional request-scoped SSE.
Local MCP needs no authorization	Local process and filesystem authority still require controls.

---

Frequently asked questions

These answers are visible reader guidance. Their presence does not imply eligibility for search-result enhancements.

Conclusion

Browse the unified evidence library and editorial policy for source, durability, correction, and review rules.

MCP’s three-part architecture survived the protocol’s most important redesign.

The host remains the coordinator: it owns the model experience, user permissions, context, cross-server planning and client lifecycle. The client remains the protocol component for one server: it carries version and capabilities, sends requests, manages transport and isolates that server relationship. The server remains the capability provider: it describes tools, resources, prompts and extensions, executes or delegates operations, and enforces authorization against its own systems.

What changed in 2026 was not the existence of those roles. It was the assumption that they needed an initialized, connection-scoped protocol session. Modern MCP makes requests self-describing, adds discovery, replaces ordinary server-initiated requests with explicit round-trip patterns, and supports ordinary horizontally scaled HTTP infrastructure.

That distinction resolves most of the recurring confusion:

host ≠ client ≠ server
logical role ≠ product name
client relationship ≠ network connection
server identity ≠ process
stateless protocol ≠ stateless application
interoperability ≠ identical host behavior

An accurate architecture guide must therefore do two things at once: preserve the durable host–client–server model, and freeze every lifecycle statement to the specification version in which it was true.

---

Update log

• August 25, 2026: Initial publication against MCP 2026-07-28; integrated the checksum-verified 57-file package, normalized the heading outline, mapped 50 main-body sources into the site-wide evidence library, replaced the embedded FAQ with all 59 supplied questions, and rechecked current product claims against official first-party documentation. Corrections cover Anthropic connector surfaces, ChatGPT plan and tunnel scope, the Agents SDK server-role boundary, the GitHub Copilot cloud-agent rename, separate Cursor surfaces, VS Code Agent Host terminology, Zed worktree trust, and JetBrains server transports.

Sources and methodology

This article is derived from a checksum-verified research package containing 68 evidence records, 122 registered claims, 13 paired datasets, 18 visual briefs, 78 supporting-content proposals, and a source-usage audit. The raw package remains unchanged; the renderer reconciles package-local citations, current first-party URLs, product-scope corrections, canonical URLs, accessible tables, visual reuse, and internal links.

Browse all 50 main-body records in the source library and review the methodology and update rules.