The MCP Architecture and Mental Model

Recall Module 1’s own closing promise — this module builds the complete, real mental map every concept in this course will slot into. Get this map genuinely clear now, and nothing later will feel like an unexplained new term.

The full architecture

Here’s the real, complete shape of an MCP-connected system, from a user’s real request all the way to an external system actually doing something.

flowchart TD
    U[User] --> H[Host]
    H --> C[MCP Client]
    C --> S[MCP Server]
    S --> T[Tools]
    S --> R[Resources]
    S --> P[Prompts]
    T --> E[External Systems]
    R --> E

Let’s walk through this slowly, since each layer answers a genuinely distinct, real question.

Host is the real, actual AI application the user interacts with — Claude Desktop, an IDE, a custom enterprise assistant. It owns the real user experience.

MCP Client lives inside the Host and maintains one real, live connection to exactly one MCP Server. A single Host genuinely runs several Clients at once, one per connected Server — covered precisely in the next module.

MCP Server is a real, separate program exposing capabilities — it never talks to the user directly, only to its connected Client.

Tools, Resources, Prompts are the three real capability types a Server can expose — recall your tool-calling coursework’s own real distinction between actions and data; MCP formalizes this into three genuinely separate categories, each covered in its own dedicated module.

External Systems are the real, actual things being touched — a database, GitHub, a filesystem — the Server’s own real, internal implementation detail.

Seeing the map with one real, concrete example

Let’s trace one real, complete request through every layer, so the map isn’t just abstract boxes.

We’ll follow a genuine, real question — “what’s in my README” — from the user all the way to a real answer.

User asks: "What's in my README?"
    ↓
Host (Claude Desktop) receives the question
    ↓
MCP Client (inside Claude Desktop) is already connected to a Filesystem MCP Server
    ↓
Client sends a real, structured request: "read this resource"
    ↓
Filesystem MCP Server reads the actual, real file from disk
    ↓
Server returns the real file content back through the Client
    ↓
Host hands that content to the LLM
    ↓
User receives a real, grounded answer

Notice the LLM itself never touches the filesystem directly — recall this exact same separation from your agent orchestration coursework’s own tool-calling discipline. The Client and Server handle the real, actual mechanics; the model only ever reasons over what comes back.

Where each real term you’ll meet later actually fits

You’ll encounter several more, real terms throughout this course — worth placing precisely now.

• Capability is the general, real term for anything a Server exposes — a Tool, a Resource, or a Prompt are each one specific kind of capability.
• Transport is the real, literal communication channel between a Client and Server — covered fully in Module 8.
• Session / Lifecycle is the real, ordered sequence a Client and Server go through — connect, initialize, negotiate, use, close — covered fully in Module 4.

Common mistakes worth avoiding

Assuming the Host and the Client are the same thing. Recall this module’s own real distinction — the Host is the whole application; the Client is one, specific connection-management component living inside it. The next module makes this precise with real, side-by-side examples.

Assuming a Server can talk directly to the user or the LLM. Recall this module’s own real trace — a Server only ever talks to its connected Client. Every real response passes back through the Client and the Host before ever reaching the model.

Treating Tools, Resources, and Prompts as interchangeable. Recall this module’s own real distinction — they’re three genuinely separate capability types, each with its own real purpose, covered in their own dedicated modules.

What you should take away from this module

• The real, complete chain is User → Host → MCP Client → MCP Server → External System, with the LLM only ever reasoning over what comes back through this chain.
• A Host owns the real user experience; a Client manages one real, live connection; a Server exposes real capabilities — three genuinely distinct, real roles.
• Tools, Resources, and Prompts are the three real capability types a Server can expose, each covered fully in its own module.

Where this goes next

The next module makes the Host/Client/Server distinction completely precise, using two genuinely different, real-world examples side by side, so this critical distinction never gets blurred again.