Every AI agent you use — Claude Desktop, Cursor, Windsurf, VS Code Copilot — runs on the same 3-layer architecture. Most developers don't know it exists. They just see an AI that can somehow read their GitHub, send Slack messages, or query their database.

Under the hood, it's all MCP — the Model Context Protocol. And once you understand its architecture, everything about how AI agents work clicks into place.

The N×M Problem

Before MCP, every AI app had to build a custom integration for every external service. 5 AI apps connecting to 5 services meant 25 separate integrations. Each one fragile, proprietary, and maintained in isolation.

Claude Desktop Cursor VS Code Copilot Windsurf GitHub Slack PostgreSQL Google Drive 4 × 4 = 16 custom integrations. None reusable.

MCP solved this with a universal protocol. Build one MCP server for GitHub, and every MCP-compatible AI app can connect to it. Instead of N×M integrations, you get N+M. The same idea as USB — one standard plug, everything works.

The 3-Layer Architecture

Every MCP system has exactly three layers: the Host, the Client, and the Server. Understanding what each one does — and what it doesn't do — is the key to understanding how AI agents actually talk to the outside world.

HOST The app you interact with Claude Desktop / Cursor / VS Code Manages UI, session, LLM calls Orchestrates multiple Clients Security & consent enforcement CLIENT Lives INSIDE the Host 1 Client per Server Maintains connection Protocol translation JSON-RPC messaging SERVER Connects to external services Exposes: Tools, Resources, Prompts Talks to GitHub, Slack, DBs Lightweight & stateless One Server = one service

Layer 1: The Host

The Host is the application you actually interact with — Claude Desktop, Cursor, VS Code with Copilot. It's responsible for the UI, managing your session, making LLM calls, and orchestrating multiple Clients. When you type a message and hit enter, the Host is what receives it.

Crucially, the Host is also the security layer. It decides which tools the AI can use and enforces user consent before any action with side effects.

Layer 2: The Client (The Misunderstood One)

This is where most people get confused. The Client is not a separate application. It lives inside the Host. There's one Client per Server connection. If your Claude Desktop is connected to both a GitHub server and a Slack server, there are two Clients running inside that Host.

The Client's job is protocol translation — it takes what the LLM wants to do and translates it into JSON-RPC messages that the Server understands. It maintains the connection, handles the handshake, and routes messages back and forth.

Layer 3: The Server

The Server is what actually connects to the outside world. One Server per external service — a GitHub server, a Slack server, a PostgreSQL server. Each one exposes three types of capabilities: Tools (actions the model can invoke), Resources (read-only data for context), and Prompts (reusable templates the user selects).

Servers are designed to be lightweight and mostly stateless — a thin interface layer over the external system, not a stateful application.

JSON-RPC 2.0: The Wire Protocol

Every message between Client and Server uses JSON-RPC 2.0. It's not REST, not GraphQL — it's a simple request-response protocol where every message has a method name, parameters, and an ID.

// Client → Server: "What tools do you have?"
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// Server → Client: "Here's what I can do"
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [{
      "name": "create_issue",
      "description": "Create a GitHub issue",
      "inputSchema": { ... }
    }]
  }
}

The discovery phase happens at session start — the Client asks the Server what it can do, and the Server lists its Tools, Resources, and Prompts. Then the LLM can reason about which ones to use during a conversation.

Transport: stdio vs HTTP+SSE

MCP supports two main transport methods:

stdio Server runs as a local subprocess Communication over stdin/stdout Best for: local dev tools, file access HTTP + SSE Server runs as a remote service HTTP POST for requests, SSE for streaming Best for: cloud APIs, shared services

stdio means the Host spawns the Server as a local subprocess and communicates over standard input/output. Fast, simple, no network involved. Use this for local tools, file system access, and development.

HTTP+SSE means the Server runs as a remote service. The Client sends requests via HTTP POST and receives streaming responses via Server-Sent Events. Use this for cloud APIs, shared team services, and production deployments.

The Full End-to-End Flow

Here's what actually happens when you ask Claude Desktop "create a GitHub issue for this bug":

1. You type message Host receives it 2. Host calls LLM with available tools list 3. LLM decides use create_issue tool 4. Client routes JSON-RPC to Server 5. Server calls GitHub API 6. GitHub responds issue #42 created 7. Client returns result to Host 8. LLM responds "Created issue #42"

Eight steps. The user sees one message and one response. Everything in between — the LLM reasoning, the Client routing, the Server calling GitHub, the response flowing back — is invisible. That's the entire point of MCP.

Real World: Claude Desktop + GitHub

Here's what the actual configuration looks like to connect Claude Desktop to a GitHub MCP server:

// claude_desktop_config.json
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx"
      }
    }
  }
}

That's it. One config block. The Host (Claude Desktop) reads this, spawns the server as a subprocess via stdio, the Client inside Claude Desktop connects to it, discovers its tools during the handshake, and now the LLM can create issues, read repos, manage PRs — all through a standard protocol.

Final Thoughts

MCP's 3-layer architecture — Host, Client, Server — is the plumbing that makes AI agents actually useful. Without it, every integration is a one-off hack. With it, you build once and every AI app can connect.

The Host is what you see. The Client is the translator you don't see. The Server is the bridge to the outside world.

That's how AI talks to GitHub, Slack, and everything else.