Back to Blog
MCP Architecture: How MCP Works (2026)
Share:
MCP works on a client-server architecture with three roles — a host (the AI app), a client inside it, and servers that wrap external tools — exchanging JSON-RPC messages so a model can discover and call real capabilities. When you ask an AI to do something it can't answer from memory, that request flows through this architecture — the open standard Anthropic introduced in 2024 — and back with live results. This guide walks the full MCP architecture and the exact data flow, one step at a time. For the concept in plain terms first, see what MCP is; this page is the deeper "how it's built and how data moves" companion.
Last updated: July 2026. The MCP architecture below is stable, but transports and extensions evolve — see the official architecture docs for the current spec.
The MCP Architecture: Three Roles
MCP is a client-server protocol, but the accurate picture has three parts, not two:
- Host — the user-facing AI application: Claude Desktop, Cursor, VS Code, or a custom agent. It's what you interact with, and it holds one or more clients.
- Client — a connector inside the host that manages exactly one connection to one server. It handles the handshake, session, and capability discovery for that server.
- Server — a lightweight, standalone program that wraps an external system (GitHub, a Postgres database, your filesystem) and exposes its capabilities in a standard way.
The relationship is one host → many clients → one server each. So a single editor can hold a client for a GitHub server and another for a database server simultaneously, each isolated.
┌─────────────────────────── HOST (Claude, Cursor, VS Code) ───────────────────────────┐
│ │
│ ┌─────────┐ JSON-RPC ┌──────────────┐ wraps ┌────────────────┐ │
│ │ Client │ ─────────────────────▶ │ MCP Server │ ─────────▶ │ GitHub API │ │
│ └─────────┘ stdio or HTTP/SSE └──────────────┘ └────────────────┘ │
│ ┌─────────┐ ┌──────────────┐ wraps ┌────────────────┐ │
│ │ Client │ ─────────────────────▶ │ MCP Server │ ─────────▶ │ Postgres DB │ │
│ └─────────┘ └──────────────┘ └────────────────┘ │
│ ▲ the model decides which tool to call │
└────────┼──────────────────────────────────────────────────────────────────────────────┘
│
you ask the AI to do something
The MCP architecture diagram above: one host holds multiple clients, each connected to a server that wraps a different real system.
How Data Flows Through MCP
Here's the sequence when you ask an AI something that needs a real tool — the heart of how MCP works:
- Capability discovery. On connecting, the client asks the server what it offers, and the server returns its list of tools, resources, and prompts with their schemas. The model now knows what's available.
- Context enrichment. Relevant resources the server exposes (a file, a record) can be pulled into the model's context before it answers, grounding it in real data.
- Tool invocation. When an action is needed, the model emits a structured tool call — which tool, with which arguments. The client relays that call to the server.
- Execution and response. The server translates the call into the underlying system's real operation (an API request, a SQL query), runs it, and returns a structured result. The model reads the result and produces its answer — or takes the next step.
That workflow — discover, enrich, invoke, execute — is the whole engine, and it runs the same way every time. Everything else is detail in service of it.
Under the Hood: JSON-RPC and the Handshake
The messages themselves are JSON-RPC 2.0 — the same request/response/notification format whichever transport is used. When a client first connects, it runs an initialize handshake with the server: the two exchange protocol versions and negotiate capabilities (what each side supports), and only then does normal traffic begin. From there, three message kinds flow: requests (expecting a reply, like a tool call), responses (the reply), and notifications (one-way, like a list-changed event). It's deliberately unexotic — a known, debuggable protocol rather than a bespoke one.
A tool call on the wire is just a plain JSON-RPC request and its response:
// Request — the client asks the server to run a tool
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call",
"params": { "name": "get_component", "arguments": { "name": "dialog" } } }
// Response — the server returns the result
{ "jsonrpc": "2.0", "id": 1,
"result": { "content": [ { "type": "text", "text": "// dialog.tsx source…" } ] } }
The connection is stateful: the session stays open after the handshake, so discovery runs once and every later tool call reuses it. And when a call fails, the server returns a JSON-RPC error object — a code and message — instead of a result, which the host surfaces so the model can retry or report it rather than silently guessing.
Transports: stdio vs. Streamable HTTP
The architecture supports two transports, and the choice is just where the server runs:
- stdio — the host launches the server as a local subprocess and talks to it over standard input/output. Used for local servers (a filesystem or git server on your machine).
- Streamable HTTP (with SSE) — the client connects to a remote server at a URL, with Server-Sent Events for streaming. Used for hosted servers you reach over the network.
| stdio | Streamable HTTP (SSE) | |
|---|---|---|
| Server runs | Locally, as a subprocess | Remotely, behind a URL |
| Latency | Lowest — no network hop | A network round-trip |
| Auth | Inherited from your shell | Headers / OAuth |
| Best for | Local tools (files, git) | Hosted, shared, multi-user servers |
The JSON-RPC messages are identical across both; only the pipe changes. This is why the same server can be added to different clients with only a config tweak.
What the Server Actually Exposes
A server's capabilities come in the three MCP primitives, each with a different owner:
| Primitive | Controlled by | Role in the flow |
|---|---|---|
| Tools | The model | Actions the model chooses to invoke (step 3 above) |
| Resources | The app | Data pulled into context (step 2 above) |
| Prompts | The user | Reusable templates the user triggers |
Most of the traffic is tools — the actions. We go deeper on the primitives and the protocol's origins in what MCP is.
A Worked Example
Say you ask Cursor, "add a confirmation dialog to the settings page." Cursor (the host) has a client connected to a DesignRevision MCP server. The flow: the client already discovered a get_component tool at connect time; the model invokes it with the argument dialog; the client relays the JSON-RPC call; the server executes it against the component registry and returns the real shadcn/ui dialog source plus its install command; Cursor applies it. Four steps, one dialog in your project — no custom integration written for Cursor at all. That's the architecture doing its job.
Conclusion
How MCP works comes down to a simple architecture doing a tight loop: a host holds clients, each connected to a server that wraps a real system, and they exchange JSON-RPC messages to discover, enrich, invoke, and execute. Transports (stdio or HTTP/SSE) decide where the server runs; the primitives (tools, resources, prompts) decide what it offers; the four-step data flow ties it together. Understand that loop and every MCP setup — local or remote, one server or ten — is the same shape. Next: what MCP is for the concept, or how to add a server to put it to work.
Related Resources
Frequently Asked Questions
-
MCP uses a client-server architecture with three roles. The host is the AI application you use (Claude Desktop, Cursor, an agent). The client is a connector inside the host that manages one connection to a server. The server is a lightweight program that wraps an external system — a database, GitHub, your filesystem — and exposes its capabilities. Messages between client and server are JSON-RPC over a transport.
-
Four steps. (1) Discovery: the client asks the server what tools, resources, and prompts it offers. (2) Enrichment: relevant context from the server is made available to the model. (3) Invocation: when an action is needed, the model emits a structured tool call, which the client relays to the server. (4) Execution: the server runs it against the real system and returns the result, which the model uses to answer.
-
An MCP server advertises a set of capabilities and waits for calls. On connection it completes a handshake and tells the client which tools, resources, and prompts it supports. When the client sends a tool call (as JSON-RPC), the server translates it into the underlying system's real operation — an API request, a SQL query, a file read — runs it, and returns a structured result. It's a thin, standardized wrapper around something that already exists.
-
MCP messages are JSON-RPC 2.0. They travel over one of two transports: stdio, where the client launches the server as a local subprocess and talks over standard input/output, or streamable HTTP (with SSE for streaming), used for remote servers reachable at a URL. The message format is identical either way; only the pipe differs.
-
The host is the app a human uses; the client is the protocol connector living inside the host (one per server); the server is the external program exposing tools. A single host can run several clients, each linked to a different server — so Cursor (host) might hold one client for a GitHub server and another for a database server at the same time.
-
Because a model on its own can't reach your tools or live data — it only knows its training. An MCP server is the standardized bridge that lets any MCP client connect to a specific system and call it safely, without a custom integration written for every app. Build the server once, and every MCP-speaking AI app can use it.
Join 50k+ subscribers
Web dev, SaaS, growth & marketing. Weekly.
Keep Learning
More articles you might find interesting.
