MCP architecture explained: hosts, clients, and servers

The Host is the AI application the user directly interacts with. Examples include Claude Desktop, Cursor, VS Code with GitHub Copilot, Windsurf, and Claude Code CLI. The host is responsible for creating and managing MCP client instances, enforcing security policies (which servers are allowed, what permissions they have), mediating between the AI model and the MCP clients, and presenting server capabilities to the user interface. A single host can create multiple clients, each connected to a different server.

Each MCP Client maintains a 1:1 connection with exactly one MCP Server. The client handles protocol version negotiation during the initialization handshake, discovers the server's capabilities (which tools, resources, and prompts it offers), routes requests from the host to the server and responses back, and manages the connection lifecycle (connect, reconnect, disconnect). The host creates one client per server configuration entry. If you have three servers in your config, the host runs three clients.

1// Conceptual: how a host creates clients (simplified)
2// This is internal to the host — you do not write this code
3//
4// for each server in config:
5//   client = new McpClient()
6//   client.connect(server.transport)
7//   client.initialize()  // handshake + capability discovery
8//   host.registerClient(client)

The MCP Server is the component you build or configure. It is a lightweight process that connects to one external service and exposes that service's functionality through MCP's three capability types: tools (model-invoked actions), resources (application-loaded data), and prompts (user-selected templates). Servers run as separate processes — either launched by the host (stdio transport) or running independently (Streamable HTTP transport). Servers must never assume anything about which host is connecting; they speak pure MCP protocol.

1import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
2import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
3
4// A server declares its identity and version
5const server = new McpServer({
6  name: "weather-service",
7  version: "1.0.0",
8});
9
10// Then exposes capabilities (tools, resources, prompts)
11// ... tool and resource definitions go here ...
12
13// Finally connects via a transport
14const transport = new StdioServerTransport();
15await server.connect(transport);

When a user asks Claude Desktop 'What is the weather in Tokyo?', here is what happens: (1) The host sends the user's message to the AI model. (2) The model decides it needs the 'get_weather' tool and returns a tool_use request. (3) The host finds which client is connected to the weather server. (4) The client sends a JSON-RPC 'tools/call' request to the server over stdio or HTTP. (5) The server calls the weather API, gets the result, and returns a JSON-RPC response. (6) The client passes the result back to the host. (7) The host feeds the tool result to the model. (8) The model generates a natural language response for the user.

1// JSON-RPC request from client to server
2{
3  "jsonrpc": "2.0",
4  "id": 1,
5  "method": "tools/call",
6  "params": {
7    "name": "get_weather",
8    "arguments": { "city": "Tokyo" }
9  }
10}
11
12// JSON-RPC response from server to client
13{
14  "jsonrpc": "2.0",
15  "id": 1,
16  "result": {
17    "content": [
18      { "type": "text", "text": "Tokyo: 18°C, partly cloudy, humidity 65%" }
19    ]
20  }
21}

MCP supports two transport mechanisms. Stdio transport is used for local servers: the host launches the server as a child process and communicates over stdin/stdout. This is the most common setup — fast, secure (no network), and simple. Streamable HTTP transport (which replaced the older SSE transport) is used for remote servers: the server runs on a separate machine and communicates over HTTP. This enables shared servers, cloud deployment, and multi-user access. Most developers start with stdio and move to Streamable HTTP when they need remote access.

1// Stdio transport — host launches server as child process
2// Config in claude_desktop_config.json:
3{
4  "mcpServers": {
5    "filesystem": {
6      "command": "npx",
7      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/docs"]
8    }
9  }
10}
11
12// Streamable HTTP transport — server runs independently
13// Config in claude_desktop_config.json:
14{
15  "mcpServers": {
16    "remote-api": {
17      "url": "https://mcp.example.com/sse"
18    }
19  }
20}

When a client connects to a server, they perform an initialization handshake. The client sends an 'initialize' request with its protocol version and capabilities. The server responds with its own protocol version, capabilities (which of tools, resources, and prompts it supports), and server info. The client then sends an 'initialized' notification to confirm. Only after this handshake can the client call tools or read resources. If the protocol versions are incompatible, the connection fails gracefully.

1// Step 1: Client sends initialize request
2{ "jsonrpc": "2.0", "id": 1, "method": "initialize",
3  "params": {
4    "protocolVersion": "2025-03-26",
5    "capabilities": {},
6    "clientInfo": { "name": "claude-desktop", "version": "1.5.0" }
7  }
8}
9
10// Step 2: Server responds with its capabilities
11{ "jsonrpc": "2.0", "id": 1,
12  "result": {
13    "protocolVersion": "2025-03-26",
14    "capabilities": { "tools": {}, "resources": {} },
15    "serverInfo": { "name": "weather-service", "version": "1.0.0" }
16  }
17}
18
19// Step 3: Client confirms
20{ "jsonrpc": "2.0", "method": "notifications/initialized" }