MCP Architecture — Model Context Protocol

MCP has a small, precise vocabulary. Get these four terms right and every tutorial becomes obvious.

The pieces

┌────────────┐    MCP    ┌────────────┐    ┌────────────┐
│ MCP HOST   │ ────────> │ MCP CLIENT │───>│ MCP SERVER │
│ (Claude,   │           │ (1 per      │    │ (provides  │
│  Cursor)   │           │  server)    │    │  tools)    │
└────────────┘           └────────────┘    └────────────┘

Host — the AI application (Claude Desktop, Cursor, Claude Code). It wants to use tools.
Client — a connection the host opens to one server. 1:1 with a server.
Server — a program exposing tools/resources/prompts. It does the real work.
Transport — how client and server talk: stdio (same machine, spawned process) or HTTP/SSE (network).

Lifecycle

The host reads its config and launches each server (e.g. npx -y @modelcontextprotocol/server-filesystem).
The client and server handshake — exchange capabilities.
The server announces its tools, resources, and prompts.
When the user asks something, the model calls a tool through the host.
The server runs the tool and returns a result — which becomes new context for the model.

The config format

Every client uses essentially the same JSON:

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

command + args describe how to launch the server; env passes secrets.

Why stdio is the default

Local servers are spawned as child processes and talk over stdin/stdout. That means they run on your machine with your credentials — private and controllable.

Remember: one host, many clients, many servers. The host is the brain; the servers are the hands.