MCP Architecture: How the Model Context Protocol Works Under the Hood

July 10, 2026 · 10 min read

Introduction

The Model Context Protocol (MCP) is more than just another API standard. Its architecture is deliberately designed to solve the fundamental challenge of connecting AI agents to external tools and data. In this guide, we'll break down exactly how MCP works — from the high-level client-server model down to the data layer protocol.

The Three Participants

MCP has three distinct roles:

• MCP Host — The AI application itself (Claude Desktop, Codex, or your own agent). The host initiates connections and manages security.
• MCP Client — A component within the host that maintains a dedicated connection to one MCP server. A host can have multiple clients, each talking to a different server.
• MCP Server — A program that exposes tools, data sources, and prompt templates. Servers can be local (started as subprocesses) or remote (accessed over HTTP).

Client-Server Architecture

MCP follows a strict client-server model:

Host (e.g., Claude Desktop)
  |
  +-- Client 1 ----> Server A (Filesystem)
  |
  +-- Client 2 ----> Server B (GitHub)
  |
  +-- Client 3 ----> Server C (Database)

Each client maintains a dedicated 1:1 connection with its server. Local servers (using stdio transport) typically serve one client at a time. Remote servers (using Streamable HTTP) can serve many clients concurrently.

Transport Layer

MCP supports two transport mechanisms:

Stdio Transport (Local)

The host launches the MCP server as a subprocess and communicates via stdin/stdout. This is the simplest setup for development:

Host launches: npx -y @modelcontextprotocol/server-filesystem .
Host <-> Server: JSON-RPC messages over stdin/stdout

Streamable HTTP Transport (Remote)

For production, servers run as HTTP endpoints. The client connects via SSE (Server-Sent Events) for streaming responses and POST for requests:

Client --POST--> Server: Request
Client <--SSE--- Server: Streaming response

Data Layer Protocol

MCP uses JSON-RPC 2.0 as its message format. Every message is a JSON object with jsonrpc, method, and params fields.

Lifecycle

1. Initialization — Client and server exchange protocol versions and capabilities. The client sends an initialize request; the server responds with its supported features.
2. Tool Discovery — The client calls tools/list to get all available tools. Each tool has a name, description, and input schema (JSON Schema format).
3. Tool Execution — The client calls tools/call with the tool name and arguments. The server executes and returns results.
4. Notifications — Servers can push notifications (e.g., notifications/tools/list_changed) when available tools change.

Example: Tool Discovery Request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

Example: Tool Discovery Response

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "read_file",
        "description": "Read contents of a file",
        "inputSchema": {
          "type": "object",
          "properties": {
            "path": { "type": "string" }
          },
          "required": ["path"]
        }
      }
    ]
  }
}

Example: Tool Execution

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "read_file",
    "arguments": { "path": "/data/config.json" }
  }
}

Resources and Prompts

Besides tools, MCP servers can expose:

• Resources — Read-only data sources (files, database records, API responses). Accessed via resources/read.
• Resource Templates — Parameterized resource URIs (e.g., file://{path}).
• Prompts — Pre-defined prompt templates that guide the LLM on how to use tools effectively.

Security Model

MCP leaves security to the host application. Key considerations:

• The host controls which servers to launch and their permissions
• Remote servers need OAuth 2.0 or API tokens
• Stdio servers inherit the host's filesystem permissions
• Input validation is the server's responsibility

Why This Design Matters

MCP's architecture solves three key problems:

• Discovery — Tools are discoverable at runtime, no hardcoded integrations needed
• Isolation — Each server runs in its own process/context, so a crash doesn't take down the agent
• Composability — Add new capabilities by plugging in servers, not rewriting code

This design is what makes MCP a true "USB-C port for AI" — one protocol that works with any tool, any data source, any model.