03. Architecture: Client vs Server

Chapter 3 of 22 · 15 min

KEY INSIGHT

MCP follows a strict client-server model where the AI application drives requests and the server provides capabilities without knowing which AI framework initiated the connection. MCP architecture separates concerns clearly. The server owns the capabilitiesΓÇöit exposes tools, resources, and prompts. The client owns the AI applicationΓÇöit decides when to call capabilities and how to use responses. **Server Responsibilities:** MCP servers implement the server-side of the protocol. They: - Accept connections on configured transport mechanisms - Declare capabilities during initialization - Handle method calls and return results - Send notifications when state changes (resource updates, tool list changes) - Handle authentication and authorization if required - Manage their own state independently of client connections Servers do not initiate requests. They respond to client calls, which keeps their implementation simpler and more predictable. **Client Responsibilities:** MCP clients connect to servers and use their capabilities. They: - Initiate protocol handshakes - Handle server capabilities and adapt behavior accordingly - Call methods and process responses - Handle notifications appropriately - Cache capability information to avoid repeated discovery A single client can connect to multiple servers simultaneously. The client mediates between the AI application and potentially many backend services. **Transport Options:** MCP supports two primary transport mechanisms: **stdio transport** uses standard input and output streams. This works well for local integrations where the server runs as a subprocess. Communication is local, low-latency, and requires no network configuration. ```python # stdio transport setup (conceptual) import sys import json # Server reads requests from stdin for line in sys.stdin: request = json.loads(line) response = handle_request(request) print(json.dumps(response), flush=True) ``` **HTTP+SSE transport** uses HTTP for client-to-server requests and Server-Sent Events for server-to-client notifications. This enables remote server deployments and works through firewalls with standard HTTP traffic. The transport choice affects deployment, latency, and security characteristics. Local tools often use stdio; remote services typically use HTTP+SSE. **Connection Lifecycle:** A client establishes one long-lived connection per server. The connection handles all capability interactions. When the AI application shuts down, the client closes connections gracefully. Understanding this architecture clarifies why MCP servers are stateless between requestsΓÇöeach request carries complete context through method parameters, and the server does not track conversation state.

EXERCISE

Draw a simple diagram showing: (1) AI application, (2) MCP client, (3) MCP server, (4) backend service. Label the arrows with "stdio" or "HTTP+SSE" and indicate which component initiates each connection.