Client-Server Architecture

The Basic Architecture

MCP follows a straightforward client-server model:

┌─────────────────┐         ┌─────────────────┐
│   MCP Client    │ ◄─────► │   MCP Server    │
│  (Claude, etc.) │         │  (Your code!)   │
└─────────────────┘         └─────────────────┘
        │                           │
        │  JSON-RPC 2.0 Messages    │
        └───────────────────────────┘

MCP Clients

Clients are AI applications that want to use external capabilities. They initiate connections and send requests.

• Claude Desktop
• Claude Code CLI
• Cursor IDE
• Any application implementing the MCP client spec

MCP Servers

Servers expose capabilities to clients. This is what you'll be building in this course. A server can provide:

• Tools — Functions the AI can call
• Resources — Data the AI can read
• Prompts — Templates for AI interactions

One-to-Many Connections

A single client can connect to multiple servers simultaneously:

                    ┌─────────────────┐
                ┌──►│  File System    │
                │   │    Server       │
                │   └─────────────────┘
┌───────────┐   │   ┌─────────────────┐
│  Claude   │───┼──►│   Database      │
│  Desktop  │   │   │    Server       │
└───────────┘   │   └─────────────────┘
                │   ┌─────────────────┐
                └──►│    GitHub       │
                    │    Server       │
                    └─────────────────┘

This is powerful! Claude Desktop can simultaneously access your files, query your database, and interact with GitHub — all through MCP.

The Role of the LLM

It's important to understand that MCP sits between the client application and the server. The LLM (like Claude) is part of the client:

┌──────────────────────────────────────┐
│           MCP Client                 │
│  ┌────────────────────────────────┐  │
│  │      Claude (LLM)              │  │
│  │  "I need to read config.json" │  │
│  └────────────────────────────────┘  │
│              │                       │
│              ▼                       │
│  ┌────────────────────────────────┐  │
│  │    MCP Client Library          │  │
│  │  Translates to MCP protocol    │  │
│  └────────────────────────────────┘  │
└──────────────────────────────────────┘
               │
               │  MCP Messages
               ▼
┌──────────────────────────────────────┐
│           MCP Server                 │
│  ┌────────────────────────────────┐  │
│  │    Your Implementation         │  │
│  │  Actually reads the file       │  │
│  └────────────────────────────────┘  │
└──────────────────────────────────────┘

Request-Response Pattern

MCP uses a request-response communication pattern built on JSON-RPC 2.0. Here's a typical exchange:

1. Client sends REQUEST:
   "What tools do you have?"

2. Server sends RESPONSE:
   "I have: read_file, search_files, get_weather"

3. Client sends REQUEST:
   "Call read_file with path='/etc/hosts'"

4. Server sends RESPONSE:
   "Here's the file contents: ..."

Every request from the client gets exactly one response from the server. The server can also send notifications (one-way messages), but these are less common.

Stateful Connections

MCP connections are stateful. Once initialized, the client and server maintain context about each other:

• Protocol version — Both agree on which MCP version to use
• Capabilities — Server tells client what features it supports
• Session state — For HTTP transport, sessions can persist