Why architecture matters here
MCP client architecture matters because the client is where the user experience lives. Slow session initialization delays every startup; conflicting tool names confuse the LLM; missing approval flows create security incidents. Each is a specific mechanism the client owns.
Cost matters modestly. Client-side session pooling and connection reuse reduce overhead from many transient connections to a few durable ones.
Reliability comes from graceful handling of server failures. A crashed MCP server should not take down the client; a slow server should not stall unrelated calls. Health checks, timeouts, and fallback paths make the client robust.
The architecture: every piece explained
Walk the diagram top to bottom.
LLM Host. The application — Claude Desktop, ChatGPT, an agent runtime. It embeds an MCP client layer to talk to external servers.
MCP Client Layer. Manages sessions with configured MCP servers. Presents a unified tool/resource/prompt list to the LLM. Handles session lifecycle, errors, and reconnects.
Server List. Configuration file (mcp.json), local discovery, or dynamic addition. Each entry says how to launch or connect to a server.
Session per Server. One session per configured server. Transport-specific: spawn child process for stdio, open persistent HTTP for SSE, use short-lived requests for HTTP.
Capability Merge. After initialize handshake with each server, client aggregates tools, resources, and prompts. Server name typically prefixes tool names to prevent collisions.
Tool Namespace. Client presents tools as "server_name.tool_name" or with an origin annotation. The LLM sees a unified list; when it invokes a tool, the client routes to the correct server.
Resource Aggregator. Resource URIs are namespaced by server. Requests for mcp://serverA/resource/foo go to serverA; mcp://serverB/resource/bar go to serverB.
Approval UI. When a server requires OAuth or user consent for scopes, the client renders an approval dialog. Grants are session-scoped or persistent per user preference.
Health + Retry. Ping each server periodically. On disconnect, attempt reconnect with backoff. If reconnect fails, degrade gracefully — the affected server's tools become unavailable but others continue.
Audit + Logging. Every tool call, every resource fetch, every prompt invocation logged with server, args, result, and timestamp. Essential for debugging and compliance.
End-to-end multi-server flow
Trace a startup + call. User opens Claude Desktop. Client reads its mcp.json listing three servers: local filesystem, GitHub (HTTP), and internal database (stdio child process).
For each server, the client establishes a session. Filesystem spawns the stdio process, sends initialize. GitHub server opens HTTP; runs OAuth if needed. Database process starts. Each returns its capabilities.
Client merges: 12 tools from filesystem, 8 from GitHub, 6 from database. Client presents to the LLM as a unified list with server prefixes: filesystem.read_file, github.create_issue, db.query.
User asks Claude to "create a GitHub issue based on the errors in error.log."
Claude plans: call filesystem.read_file on error.log; parse; call github.create_issue with body derived from errors.
Client routes the read_file call to the filesystem server. Server returns the file contents. Client passes back to Claude.
Claude invokes github.create_issue. Client routes to GitHub server. Server posts to GitHub API using OAuth token. Returns issue URL.
Claude presents result to user. Audit log has both calls with full context.
Meanwhile the database server crashed. Health check notices; client marks db tools unavailable and shows a warning. Filesystem and GitHub continue. When the database server restarts, health check reconnects; tools are available again.