Intermediate

MCP Architecture

MCP has four layers: hosts (the applications embedding Claude), clients (the MCP connection manager inside each host), servers (the processes exposing tools), and transports (the mechanism carrying messages between client and server). Understanding this stack tells you where your code lives and how a tool call flows end-to-end.

Host App

Claude Desktop

Claude Code

MCP Clients

Client A

Client B

Client C

MCP Servers

Filesystem

GitHub

Postgres

Each host maintains one MCP client per connected server

Hosts

A host is any application that embeds an LLM and implements the MCP client protocol. Current examples:

Claude Code — the CLI tool; hosts MCP servers alongside a coding session
Claude Desktop — the macOS/Windows app; hosts MCP servers as background processes
Custom applications — any application you build that includes an MCP client library

The host is responsible for reading the MCP server configuration, starting server processes, and presenting the discovered tools to the LLM as part of the available tool list.

MCP Clients

The MCP client is the connection management component inside a host. Each host has one MCP client, which can maintain multiple simultaneous connections — one per configured server. The client handles:

Starting server processes (for stdio transport) or opening HTTP connections (for SSE transport)
Sending the initialise handshake to negotiate capabilities
Forwarding tool call requests from the LLM to the appropriate server
Returning tool results to the LLM conversation

As an application developer, you rarely interact with the MCP client directly — it is embedded in the host. When you configure mcpServers in settings.json, you are giving the client its server list.

MCP Servers

An MCP server is a separate process (or remote service) that exposes tools and resources. It implements the server side of the MCP protocol:

Responds to the initialise handshake with a list of capabilities
Responds to tools/list requests with tool definitions (name, description, input schema)
Responds to tools/call requests by executing the tool and returning a result
Optionally responds to resources/list and resources/read for read-only data access

Servers are process-isolated — they run independently of the host. A crash in an MCP server does not crash Claude Code or Claude Desktop. Servers can be written in any language that has an MCP SDK (Python, TypeScript) or that can implement the JSON-RPC wire protocol directly.

Transports: stdio vs SSE

The transport layer carries JSON-RPC messages between the client and server. Two transports are defined in the MCP spec:

stdio (Standard I/O)

Host launches the server as a child process
Messages sent over stdin/stdout as newline-delimited JSON
Server lives on the same machine as the host
Simple, low-latency, no networking required
Most common for local tools: filesystem, database, code execution

SSE (HTTP + Server-Sent Events)

Server runs as an HTTP service at a URL
Client sends requests via HTTP POST; server streams responses via SSE
Server can be remote (cloud-hosted, team-shared)
Requires network access; more complex to secure
Use for shared integrations across a team or org

The Request/Response Lifecycle

A complete tool call through MCP follows this sequence:

Host starts up — reads mcpServers config, launches server processes (stdio) or connects to server URLs (SSE)
Initialise handshake — client sends initialize with protocol version; server responds with its capabilities and protocol version
Tool discovery — client sends tools/list; server responds with all available tools including name, description, and input schema
Host presents tools to LLM — discovered tools are included in Claude's available tool list for the session
LLM requests a tool call — Claude returns a tool_use block naming the tool and providing inputs
Client routes the call — the MCP client sends a tools/call request to the correct server
Server executes and responds — server runs the tool handler and returns the result as JSON
Client returns result to LLM — result is added to the conversation as a tool_result message

Checklist: Do You Understand This?

Host: the application embedding Claude (Claude Code, Claude Desktop, or your own app)
Client: the MCP connection manager inside the host — one client, multiple server connections
Server: the separate process exposing tools; responds to tools/list and tools/call
stdio transport: server is a child process, communication over stdin/stdout — local, simple, most common
SSE transport: server is a remote HTTP service — use for shared, team-wide integrations
Lifecycle: start → initialise → tools/list → LLM session → tools/call → result → LLM