MCP Host vs Client vs Server: Understanding the Architecture

What if every AI app had to build its own custom connector for every tool it needed? That's exactly the problem MCP was built to solve.

Before the Model Context Protocol (MCP) existed, connecting an AI assistant to GitHub meant writing a custom GitHub integration. Connecting it to Slack meant another custom integration. Connecting it to your database? Yet another one. The result was a sprawling mess of one-off connectors - brittle, expensive to maintain, and impossible to scale.

MCP changes that. It's an open standard that gives AI applications a single, universal way to connect to any external tool, data source, or service. One protocol to rule them all.

This post is for developers and technical product managers who are new to MCP and want to understand the core MCP architecture - specifically, what the Host, Client, and Server components are, how they differ, and how they work together. Let's dig in.

---

What Is MCP? The Big Picture

MCP (Model Context Protocol) is an open standard for connecting AI applications to external data sources, tools, and systems. Think of it as the USB-C port for AI - just as USB-C gave us a single, universal connector for charging and data transfer across devices, MCP gives AI apps a single, universal way to plug into the world.

Before MCP, the integration problem looked like this: if you had N AI applications and M external tools, you needed up to N×M custom connectors. Every team reinvented the wheel. MCP collapses that into an N+M model - build your server once, connect it to any MCP-compatible app.

Quick fact: MCP was created by Anthropic engineers David Soria Parra and Justin Spahr-Summers. It was announced on November 25, 2024, as a fully open-source project. Early adopters included Block, Apollo, Zed, Replit, Codeium, and Sourcegraph.

MCP is now hosted under the Linux Foundation and has seen rapid adoption across the AI ecosystem - Claude Desktop, Cursor IDE, VS Code with GitHub Copilot, and OpenAI's ChatGPT all support it.

---

The Three Components: A Quick Overview

MCP's architecture has three distinct participants. Here's the 30-second version before we go deep:

• MCP Host - the end-user-facing AI application (e.g., Claude Desktop, Cursor). It owns the UI, manages connections, and orchestrates everything.
• MCP Client - a protocol connection layer inside the Host. Each Client maintains a dedicated 1:1 connection to one specific MCP Server.
• MCP Server - a lightweight program that exposes capabilities (tools, resources, prompts) to the AI application via the MCP protocol.

The key insight: the Host never talks to Servers directly. It always delegates through Clients. This separation is what makes the whole system clean, composable, and scalable.

---

What Is an MCP Host?

The MCP Host is the end-user-facing application - the thing you actually open and interact with. It's responsible for the UI/UX, for deciding which MCP Servers to connect to, and for creating and managing the MCP Clients that handle those connections.

Real examples of MCP Hosts include:

• Claude Desktop - Anthropic's desktop AI assistant
• Cursor IDE - the AI-first code editor
• VS Code (with GitHub Copilot or other extensions)
• Custom AI chat applications built by developers

What Does a Host Actually Do?

The Host is the orchestrator. Its responsibilities include:

• Rendering the user interface and accepting user input
• Reading the MCP Server configuration (which servers to connect to, and how - see MCP server discovery for how clients find servers automatically)
• Instantiating one MCP Client per configured Server
• Incorporating Server capabilities (tools, resources, prompts) into the AI model's context
• Routing requests from the AI model to the appropriate Client
• Presenting results back to the user

Think of the Host as the manager of a restaurant. It takes your order (your request), but it doesn't cook the food itself - it delegates to the kitchen staff (the Clients and Servers). The manager coordinates everything; the kitchen does the actual work.

---

What Is an MCP Client?

The MCP Client is an internal protocol connection layer that lives inside the Host. It maintains a dedicated, stateful 1:1 connection to exactly one MCP Server. One Host can contain many Clients - one per Server it's connected to.

The Client handles all the low-level protocol work:

• Capability handshake - negotiating what the Server supports on connection
• Session management - keeping the connection alive and stateful
• Request forwarding - sending the Host's requests to the Server
• Response handling - receiving results and passing them back to the Host

Crucially, the Client is invisible to end users. You'll never see it in a UI. It's a pure technical bridge - the plumbing that makes everything else work.

Host vs Client - What's the Difference?

This trips people up, so let's be direct.

The Host is the application you open. The Client is a connection object inside that application. They're not the same thing, even though everyday conversation sometimes uses "client" loosely to mean the whole app.

In the official MCP architecture: one Host creates multiple Clients, one per Server. So if VS Code is connected to three MCP Servers (say, GitHub, a filesystem server, and a Sentry server), VS Code is the Host and it contains three separate Client objects - each managing its own dedicated connection.

The Client is like a dedicated phone line between the manager (Host) and one specific supplier (Server). Each supplier gets their own line. The manager doesn't shout across the room - they pick up the right phone.

---

What Is an MCP Server?

An MCP Server is a lightweight program that implements the MCP protocol and exposes capabilities to AI applications. It's the thing that actually does stuff - querying databases, calling APIs, reading files, sending messages.

MCP Servers can run locally (on your machine) or remotely (in the cloud). Either way, from the Host's perspective, they look the same.

Every MCP Server exposes some combination of three core primitives:

1. Tools - executable functions the AI can invoke (model-controlled). Examples: search the web, send a Slack message, create a GitHub issue, run a terminal command.
2. Resources - read-only data the AI can access (application-controlled). Examples: file contents, database records, API responses, documentation pages.
3. Prompts - pre-built prompt templates (user-controlled). Examples: code review templates, summarisation prompts, few-shot examples for a specific domain.

Real-world MCP Servers you can use today include:

• GitHub MCP Server - read repos, create issues, open PRs
• Slack MCP Server - send messages, read channel history
• AWS MCP Server - interact with AWS services
• Figma MCP - read designs and component data
• Playwright MCP - browser automation and web scraping
• Filesystem server - read and write local files
• Postgres/database servers - query databases directly

Local vs Remote MCP Servers

Local MCP Servers run on the user's machine and communicate via stdio transport (standard input/output). They're ideal for accessing local files, local databases, or running terminal commands. Because there's no network hop, they're fast and simple to set up.

Remote MCP Servers run on a cloud server and communicate via Streamable HTTP transport (HTTP POST with optional Server-Sent Events for streaming). They're the right choice for SaaS integrations - Slack, GitHub, Notion, Salesforce - where the data lives in the cloud. Remote servers support standard HTTP authentication including OAuth, bearer tokens, and API keys. (Our guide to choosing the right MCP transport compares the trade-offs in detail.)

---

How MCP Host, Client, and Server Work Together

Here's the full end-to-end flow, step by step:

1. User opens a Host app (e.g., Claude Desktop) and it reads the configured list of MCP Servers.
2. The Host creates one MCP Client per configured Server - three servers, three Clients.
3. Each Client opens a session with its Server and performs a capability handshake using JSON-RPC 2.0 - negotiating protocol version and supported features.
4. The Server responds with its list of available tools, resources, and prompts (e.g., tools/list returns all callable functions).
5. The Host incorporates these capabilities into the AI model's context - the LLM now "knows" what tools are available.
6. User sends a message or request (e.g., "Check my latest GitHub issues").
7. The AI model decides which tool or resource to use based on the available capabilities in its context.
8. The Host instructs the relevant Client (the GitHub Client, in this case) to send the request to its Server.
9. The Server executes the action - queries the GitHub API, fetches the issues - and returns the result.
10. The Client passes the result back to the Host.
11. The Host feeds the result into the model's context, and the AI generates its final response for the user.

A concrete example: If you ask Claude Desktop to "check my latest GitHub issues", the Host tells the GitHub MCP Client to query the GitHub MCP Server. The Server calls the GitHub API, fetches your open issues, and returns structured data. The Client passes it back to the Host, which feeds it to Claude. Claude reads the issues and gives you a summary - all in a matter of seconds.

---

MCP Host vs Client vs Server: At a Glance

Component	What It Is	Who Sees It	Key Role	Examples
MCP Host	The end-user AI application	End users	Owns UI, manages Clients, orchestrates requests	Claude Desktop, Cursor, VS Code
MCP Client	Internal connection layer inside the Host	Developers only	Maintains 1:1 session with one Server; handles protocol	Created by the Host at runtime
MCP Server	Standalone program exposing capabilities via MCP	Developers / DevOps	Exposes tools, resources, and prompts to AI apps	GitHub MCP Server, Slack MCP, filesystem server

---

MCP vs Traditional API Integrations: Why It Matters

MCP is not an API - it's a protocol that standardises how AI apps connect to tools, replacing the need for custom API integrations for every combination. (For the full breakdown, see MCP vs REST API.)

The old way: if you had 5 AI apps and 10 tools, you potentially needed 50 custom connectors. Each one had its own auth flow, data format, error handling, and maintenance burden. The N×M problem.

With MCP: each tool builds one MCP Server. Each AI app implements the MCP Host/Client pattern once. Now any app can connect to any server. That's the N+M solution - and it's why MCP vs API is such a common question.

To be clear: MCP Servers themselves often call REST APIs under the hood. The GitHub MCP Server calls GitHub's REST API. But from the AI app's perspective, it just speaks MCP - it doesn't need to know anything about GitHub's specific API surface, auth tokens, or response formats. That complexity lives in the Server, not the Host.

The result: faster development, less duplication, and a growing ecosystem of ready-to-use Servers that any MCP-compatible app can plug into immediately.

---

Real-World Use Cases for MCP Architecture

The MCP protocol architecture unlocks a wide range of practical applications:

• Developer tools: Cursor and VS Code use MCP to connect to GitHub (read issues, create PRs), run tests, query documentation, and interact with cloud infrastructure - all from within the editor.
• Enterprise AI: Internal AI assistants connect to knowledge bases, CRMs like Salesforce, ticketing systems like Jira, and HR platforms - giving employees a single AI interface to every internal system. (At this scale, an MCP gateway architecture often beats wiring each server directly.)
• Personal productivity: Claude Desktop with a filesystem MCP Server can read your local notes, drafts, and documents. Add a calendar MCP Server and it can schedule meetings based on your availability.
• Data analysis: AI agents query live databases via a Postgres MCP Server, generate SQL on the fly, and return formatted reports - no BI tool required.
• Customer support: AI assistants pull live order data, shipping status, and account history from e-commerce backends via MCP, resolving queries without a human agent.

---

Key Takeaways

Summary - the most important things to remember:

• MCP (Model Context Protocol) is an open standard created by Anthropic, announced November 25, 2024, for connecting AI apps to external tools and data.
• The MCP architecture has three components: Host, Client, and Server - each with a distinct, non-overlapping role.
• The Host is the user-facing app (Claude Desktop, Cursor). It creates and manages Clients.
• The Client is an internal connection object inside the Host - one Client per Server, invisible to end users.
• The Server is a standalone program that exposes tools, resources, and prompts via the MCP protocol.
• Servers expose three primitives: Tools (executable actions), Resources (read-only data), and Prompts (reusable templates).
• MCP solves the N×M integration problem - build a server once, connect it to any MCP-compatible app.
• MCP uses two transport mechanisms: stdio (local) and Streamable HTTP (remote/cloud).

---

Frequently Asked Questions

What is the difference between MCP Host and MCP Client?

The Host is the end-user application (e.g., Claude Desktop or Cursor). The Client is a connection object that lives inside the Host - it manages the protocol session with one specific MCP Server. One Host can contain many Clients. In everyday conversation, "client" is sometimes used loosely to mean the whole app, but in the official MCP architecture they're distinct components.

Can one MCP Host connect to multiple MCP Servers?

Yes - and this is a core feature of the design. A Host creates one MCP Client per Server, so it can maintain simultaneous connections to as many Servers as needed. VS Code, for example, can connect to a GitHub Server, a filesystem Server, and a Sentry Server all at once, each through its own dedicated Client.

What is an MCP Server used for?

An MCP Server exposes capabilities to AI applications - specifically tools (executable functions like "send a Slack message"), resources (read-only data like file contents or database records), and prompts (reusable templates). It's the component that does the actual work: calling APIs, querying databases, reading files, and returning results.

Is MCP the same as an API?

No. MCP is a protocol - a standardised communication layer - not an API. Traditional APIs require custom integration code for every app-tool combination. MCP provides a single standard that any AI app can use to connect to any MCP Server. MCP Servers often call REST APIs internally, but the Host only ever speaks MCP - it's abstracted from the underlying API details.

Who created the Model Context Protocol?

MCP was created by David Soria Parra and Justin Spahr-Summers at Anthropic. It was announced on November 25, 2024, as an open-source project. It's now hosted under the Linux Foundation and has been adopted by major AI platforms including Claude, ChatGPT, VS Code, and Cursor.

What transport protocols does MCP use?

MCP supports two transport mechanisms:

• Stdio transport - uses standard input/output streams for local process communication. Best for local MCP Servers running on the same machine.
• Streamable HTTP transport - uses HTTP POST with optional Server-Sent Events (SSE) for streaming. Best for remote/cloud MCP Servers. Supports OAuth, bearer tokens, and API keys for authentication.

Do I need to build my own MCP Server?

Not necessarily. There's already a large and growing ecosystem of pre-built MCP Servers for popular tools - GitHub, Slack, Postgres, Figma, AWS, Playwright, and many more are available in the official MCP servers repository. You only need to build your own if you're connecting to a proprietary internal system or a tool that doesn't have an existing Server. (See our step-by-step guide to building an MCP server in Python.)

---

Useful Sources

• Anthropic - Introducing the Model Context Protocol - the original announcement, November 25, 2024.
• MCP Official Documentation - Architecture Overview - the authoritative technical reference for Host, Client, Server, and transport layers.
• MCP Specification on GitHub - modelcontextprotocol/modelcontextprotocol - the full open-source specification and JSON schema.
• MCP Reference Server Implementations - official pre-built MCP Servers for GitHub, Slack, Postgres, filesystem, and more.

---

And if you're ready to go hands-on, check out our step-by-step guide to building your first MCP server - writing, testing, and deploying your own MCP Server from scratch.