MCP Client vs Server vs Host: The Mental Model That Unlocks Everything

If MCP feels abstract, start with the three roles the official docs define: host, client, and server.

The three roles (official model)

The MCP architecture overview describes a client-server design where:

The docs’ VS Code example: when VS Code connects to the Sentry MCP server, the runtime creates an MCP client for that connection. When it also connects to a local filesystem server, it creates another client. One host, many clients, many servers.

Official overview: Architecture overview.

Local vs remote servers

The same architecture page is explicit:

• Local servers often use the stdio transport (client launches a subprocess on the same machine).
• Remote servers often use the Streamable HTTP transport (independent process, many clients).

“MCP server” always means the program that serves context — not where it runs.

What each role is responsible for

Host (AI application)

• Owns the user-facing app and model session
• Instantiates clients and loads which servers to connect
• Decides how tool results and resources are shown to the user
• Does not implement every integration itself — it consumes servers

Client (connection manager)

• Speaks the MCP data layer (JSON-RPC 2.0) to one server
• Runs lifecycle initialization and capability negotiation (lifecycle)
• Discovers primitives (tools/list, resources/list, prompts/list, …) and invokes tools (tools/call)

Server (context provider)

• Exposes tools, resources, and/or prompts (see server concepts)
• May hold credentials to upstream systems behind those tools
• Should be usable by any compliant host/client — the protocol is the contract

Two layers (data + transport)

Officially, MCP has:

1. Data layer — JSON-RPC messages, lifecycle, primitives (tools/resources/prompts), notifications
2. Transport layer — how messages move (stdio, Streamable HTTP, or custom transports)

Same data layer; different wires. Details: Architecture overview and Transports (2025-11-25).

Common confusions

1. “I installed MCP in Cursor” — you configured the host to start or call a server.
2. “My server works locally but not for my team” — stdio is tied to a local process; teammates need a remote server (typically Streamable HTTP) or a shared host.
3. MCPLambda — deploys and operates your MCP servers. Separately, the MCPLambda MCP server is a management server so agents can create deployments. Different jobs.

Mental model checklist

• Who is the human talking to? → Host
• What maintains one wire to one server? → Client
• What executes tools / serves data? → Server

Worked scenario: “I installed MCP” means three different things

In a meeting, one person “installed MCP” by adding a Cursor config (host). Another “built MCP” (server). A third “debugged the client connection” (client). They talk past each other for twenty minutes.

You standardize language: the host is the AI app; the client is the connection object inside it; the server is what you deploy or run. MCPLambda hosts servers; Cursor is a host; the wire is client↔server over stdio or Streamable HTTP.

After that, transport and deploy conversations stop being circular.

Checklist for this topic

• Use host/client/server terms consistently in docs
• Know whether a problem is host config vs server runtime
• Remember one host can have many clients/servers
• Local vs remote is about server placement + transport
• Management MCP servers are still just servers
• Link architecture docs when onboarding

Topic-specific failure modes

Related guides

Transports · Server primitives · Architecture overview

In practice: incident labels

Tag incidents as host-config, client-transport, or server-runtime. Metrics by label quickly show whether you have a documentation problem (hosts) or an engineering problem (servers).

Diagram to paste in onboarding

User ↔ Host (Cursor/Claude/VS Code)
              ↕ MCP client (per server)
         MCP server (your process)
              ↕
         Slack / DB / API

If someone cannot point to which box is broken, they are not ready to change production config.

Takeaways

For MCP Client vs Server vs Host: The Mental Model That Unlocks Everything, remember three things:

1. Be specific to this problem — the worked scenario ““I installed MCP” means three different things” is the failure mode you should design against, not a generic outage narrative.
2. Hosts embed clients; clients speak MCP; servers expose tools/resources/prompts — mislabeling causes bad architecture.
3. Fix connection problems at the right layer: host config vs client transport vs server process.

If you only remember one habit: when something breaks, name the layer first (host, client, or server) before changing code.

Sources

• What is MCP?
• Architecture overview
• Understanding MCP servers
• Specification (2025-11-25)

Next steps

Read tools, resources, and prompts or transports.