MCP (Model Context Protocol) architecture splits into three parts: the Host (the app you use, like Claude Desktop or Cursor), the Client (lives inside the Host, translates AI model requests into MCP protocol messages), and the Server (runs the actual tools and returns structured JSON results). This lesson explains how a single request flows through all three.
What you will be able to do
- Trace a user request as it moves through Host, AI model, Client, and Server in an MCP-based application.
- Explain the difference between an MCP host, an MCP client, and an MCP server in plain terms.
- Identify which transport (STDIO or HTTP+SSE) fits a given MCP server setup, local versus remote.
- Distinguish MCP from a REST API when explaining the protocol to someone else.
- Recognize the JSON-RPC 2.0 message format underlying every MCP request and response.
Before you start
- Have read the first two lessons in this course: what MCP is, and why it was created (the M x N integration problem).
- Be familiar with using a chat-based AI application such as Claude Desktop, ChatGPT, or Cursor.
- No coding required for this lesson, it is conceptual.
Reference
| Component | Role | Lives where | Example |
|---|---|---|---|
| Host | Receives your message, sends it to the AI model, keeps conversation history, shows results, contains the Client | The application you interact with directly | Claude Desktop, Cursor, a voice interface |
| AI model | Reads the request and decides what tool or resource is needed | Inside the Host | Decides "I need the summarize_file tool" |
| Client | Translates the AI model's tool request into MCP protocol language, sends it to the right Server, passes the reply back | Inside the Host | Built-in MCP client, not something you interact with directly |
| Server | Runs the actual tool, resource, or prompt and returns structured data (usually JSON) | Local (on your computer) or remote (in the cloud) | Tools like get_weather, summarize_text, delete_email |
| STDIO transport | Local transport: Host launches the server as a child process, messages pass through stdin/stdout, no network needed | Local servers | File readers, code analyzers, local databases |
| HTTP + SSE transport | Remote transport: Client sends HTTP requests, Server streams responses back via Server-Sent Events | Remote servers | Remote APIs, shared team servers, cloud services |
| JSON-RPC 2.0 | Message format used by both transports: every request has a method name, parameters, and an ID; every response carries a result or an error | Both STDIO and HTTP+SSE | The standardized envelope for all MCP messages |
Common errors and fixes
| What goes wrong (common mix-up) | The fix (what's actually true) |
|---|---|
| Assuming the Host runs the tools itself | The Host only manages the interface and conversation; the Server is what actually runs the tool |
| Confusing the Client with the AI model | The Client only translates requests into MCP protocol language and routes them; the AI model is the one that decides which tool is needed |
| Treating MCP like a single point-to-point REST API connection | MCP is a standardized protocol, not one connection: one MCP Client can talk to hundreds of different Servers using the same language |
| Expecting to interact with the Client or Server directly | You never talk to the Client or Server yourself, just like you never shout your order at the kitchen; the Host is the only thing you interact with |
| Assuming every MCP server uses the same transport | Local servers use STDIO (stdin/stdout, no network); remote servers use HTTP+SSE (works across networks); the choice depends on where the server runs |
Read the full walkthrough
The complete lesson, with screenshots and any downloads, is published on Substack as part of MCP Masterclass: Connect AI to Everything.
More in this section
Continue the course
Browse all lessons in the MCP Masterclass: Connect AI to Everything course, or subscribe to the GenAI Unplugged newsletter to get new lessons in your inbox.
