The MCP Architecture
Trace the four-layer chain — Host, MCP Client, MCP Server, and Data/Service — and learn exactly what each piece does when an agent calls a tool.
When an agent uses a tool, the request doesn't magically leap from the model to your database. It travels down a short, well-defined chain and the answer travels back up the same way. Understanding this chain is the single most useful mental model in all of MCP: once you can name the four layers, everything else — the wire protocol, the primitives, the safety boundary — snaps into place.
The chain has exactly four layers. Data flows both ways: a request goes left-to-right (the model wants something) and the result comes back right-to-left.
Host ⇄ MCP Client ⇄ MCP Server ⇄ Data / Service#Layer 1 — The Host
The Host is the app the user actually interacts with — think Claude Desktop, an IDE, or your own agent. It embeds the LLM and one MCP client per server it connects to. If your host talks to three servers, it spins up three clients.
The host is where the thinking happens. The model reads the user's request, decides a tool is needed, and picks which one.
#Layer 2 — The MCP Client
The MCP Client lives inside the host. It speaks JSON-RPC 2.0, maintains the connection, and relays tool calls and results. The key rule to remember: one client talks to exactly one server (1 client ↔ 1 server). The client is the diplomat — it doesn't decide anything, it just carries messages faithfully in both directions.
The client is a phone line, not a brain
The host (with its LLM) is the person deciding what to say. The MCP client is the phone line carrying the words. The server is the person on the other end who actually does something. The client never has opinions — it just keeps the line open and passes messages faithfully in JSON-RPC.
#Layer 3 — The MCP Server
The MCP Server is what you build — your connector code. It advertises Tools, Resources & Prompts, validates inputs, and executes the real work. This is where your logic lives: which tables are visible, what a tool is allowed to do, how inputs are checked before anything touches the data.
Crucially, the server defines what each tool does. It does not decide when a tool runs — that's the host's job.
Who decides *when* a tool gets called?
#Layer 4 — The Data / Service
The bottom layer is the Data / Service — the actual resource behind the server: a database, a SaaS API, or local files. The server is its gatekeeper. The model never touches this layer directly and never holds its credentials. Every request has to pass through your server first, which is exactly what makes MCP a safe boundary.
The model never sees the raw data source
The agent can't reach the database, the API keys, or the filesystem on its own. It can only ask the server, and the server decides what to allow. That gatekeeper position is why you can enforce read-only access, scope which tables are visible, and audit every single call.
#Putting the chain together
So a single tool call travels the whole chain: the host's model decides to call a tool, the MCP client wraps that decision as a JSON-RPC message and sends it to the MCP server, the server validates the inputs and queries the data/service, and the result flows back up the same path into the model's context. Four layers, one conversation.
Because the client speaks a standard protocol, the same server works with any MCP-aware host — you can swap Claude Desktop for an IDE or your own agent without changing a line of your connector. That's the payoff of the four-layer design: clean boundaries mean each piece can change independently.
How many MCP clients does a host run if it connects to three different MCP servers?
Key takeaways
- The MCP chain has four layers: Host → MCP Client → MCP Server → Data/Service, with requests flowing down and results flowing back up.
- The Host embeds the LLM and one MCP client per server; the model decides *when* a tool is called.
- The MCP Client speaks JSON-RPC 2.0 and maintains one connection per server (1 client ↔ 1 server) — it relays, it doesn't decide.
- The MCP Server is the code you write: it advertises Tools/Resources/Prompts, validates inputs, and executes the real work.
- The Data/Service (DB, API, or filesystem) sits behind the server, which acts as its gatekeeper — the model never touches it directly.
Host: You ask the Host a question in plain language.
Put the four MCP layers in order, from the app the user interacts with down to the real resource.
Host — the app the user interacts with; embeds the LLM
MCP Client — speaks JSON-RPC 2.0, one client per server
Data / Service — the DB, API, or filesystem behind the server
MCP Server — your connector code; validates and executes
This is the JSON-RPC message the agent's MCP client sends to the server. Which layer actually runs the SQL and produces the result content?
{ "jsonrpc": "2.0", "id": 2, "method": "tools/call",
"params": { "name": "query_sales",
"arguments": { "metric": "revenue", "groupBy": "customer", "limit": 3 } } }A host is wired to a server with this config. Fill in the top-level key the host reads to find the servers it should launch.
{ "": { "sales-connector": { "command": "node", "args": ["/absolute/path/to/server.js"] } } }
A teammate describes the architecture like this. What's the mistake?
"The LLM connects straight to the database, and the
MCP server decides when each tool should be called."You're designing an MCP connector for a company's Google Calendar. Trace the four-layer chain for the request "What meetings do I have tomorrow?" For each of the four layers (Host, MCP Client, MCP Server, Data/Service), write one sentence describing what that specific layer is and what it does in this scenario. Then answer: which layer holds the OAuth credentials for the calendar, and why should it NOT be the model?
Try it yourself — a starting point to build on:
# Write your solution here