Start with the job: distinguish client responsibilities from host responsibilities

The MCP host is the application-level coordinator; an MCP client is the protocol participant connected to a server. Treating them as synonyms hides where consent, cross-server policy and per-connection state belong.

A client can negotiate and exchange protocol messages, but it should not invent application-wide authority. The host decides which servers are trusted, how capabilities reach the model and what the user can approve.

Keep this page's decision boundary canonical

Consider server discovery from the host's perspective. The host decides which configured connections are available in a workspace, how their names and descriptions reach users or models, and how conflicts between similar capabilities are resolved. A client can report what its server advertises, but it lacks the application context needed to decide whether two servers expose redundant or prohibited actions. That cross-connection inventory belongs to host policy and should remain inspectable.

Connection recovery belongs closer to the client. It tracks negotiated state, outstanding requests, notifications and errors for one server, and it should invalidate stale capabilities after a failed reinitialization. The host can decide how that failure appears and whether another workflow continues, but it should not manufacture protocol success. Keeping this distinction prevents optimistic UI state from masking a broken session and prevents one server's retry policy from affecting unrelated connections.

Data combination requires both layers. A client attributes each result to one server; the host may combine results with user input, private context or another server before a model acts. Record that aggregation as a new trust transition. Even individually approved resources can create an unintended disclosure when the host moves information between connections with different recipients, credentials or retention rules.

Make the operating boundary visible

One host can manage multiple client-server relationships. Each client tracks its server's initialization and capabilities, while the host aggregates available context and actions into a coherent application experience.

FIG. 01 / Conceptual model

Host policy, client session

Architecture map of one MCP host coordinating separate client-server connections
Conceptual model: the host owns cross-connection policy while each client owns one protocol relationship.

Build a reproducible path

For MCP Client vs Host, use a small fixture that another developer can repeat without privileged production data. Change one boundary at a time and preserve the exact configuration needed to explain how the page's decision was reached.

  1. List host-wide policies and user-facing consent decisions.
  2. Create a separate lifecycle record for each client-server connection.
  3. Keep server capabilities and errors scoped to that connection.
  4. Test one server failing without corrupting unrelated host state.

Keep secrets outside the mcp client vs host artifact. Record variable names, scopes and owners, then verify the relevant system of record whenever this tool or workflow can change external state.

Record evidence that survives a rerun

Document ownership at both levels. A connection log proves what one client saw; it does not prove the host applied the same approval, privacy or routing policy across every server.

  • Host trust policy and user interface
  • Client initialization and negotiated version
  • Per-server capability inventory
  • Cross-server data flow and failure isolation

Date the MCP Client vs Host record and keep factual observations separate from inference. If a claim depends on a hosted service, preview feature or moving SDK, name that dependency beside the claim.

Use a decision rule and a stopping rule

Place policy in the host when it spans users or servers, and protocol state in the client when it belongs to one connection. Avoid server-specific exceptions scattered through model prompts.

Disconnect one server, change its capability list and trigger a denied call. The host should update that connection without retaining stale tools or weakening controls for other clients.

FIG. 02 / Decision aid

Assign responsibility to the right layer

Decision matrix assigning consent, routing, negotiation and connection state to host or client
Decision aid: application-wide decisions belong to the host; per-server protocol state belongs to the client.

Protect against predictable failure and continue deliberately

For MCP Client vs Host, the architecture review flags three recurring failure modes: specification versions are mixed; local and remote trust boundaries are conflated; a server is recommended without permission review. Treat them as release checks, not footnotes. This page remains draft when its exact implementation or intent evidence is still research-gated.

Use the MCP architecture map next: it separates host policy, client state, server behavior and transport.

Use the MCP primitives guide next: it distinguishes resources, tools and prompts by interaction job.

Use the MCP field guide next: it reconnects the decision to protocol roles and versioned boundaries.