|
| 1 | +--- |
| 2 | +title: Architecture |
| 3 | +--- |
| 4 | + |
| 5 | +<div id="enable-section-numbers" /> |
| 6 | + |
| 7 | +The Model Context Protocol (MCP) follows a client-host-server architecture where each |
| 8 | +host can run multiple client instances. This architecture enables users to integrate AI |
| 9 | +capabilities across applications while maintaining clear security boundaries and |
| 10 | +isolating concerns. Built on JSON-RPC, MCP provides a stateful session protocol focused |
| 11 | +on context exchange and sampling coordination between clients and servers. |
| 12 | + |
| 13 | +## Core Components |
| 14 | + |
| 15 | +```mermaid |
| 16 | +graph LR |
| 17 | + subgraph "Application Host Process" |
| 18 | + H[Host] |
| 19 | + C1[Client 1] |
| 20 | + C2[Client 2] |
| 21 | + C3[Client 3] |
| 22 | + H --> C1 |
| 23 | + H --> C2 |
| 24 | + H --> C3 |
| 25 | + end |
| 26 | +
|
| 27 | + subgraph "Local machine" |
| 28 | + S1[Server 1<br>Files & Git] |
| 29 | + S2[Server 2<br>Database] |
| 30 | + R1[("Local<br>Resource A")] |
| 31 | + R2[("Local<br>Resource B")] |
| 32 | +
|
| 33 | + C1 --> S1 |
| 34 | + C2 --> S2 |
| 35 | + S1 <--> R1 |
| 36 | + S2 <--> R2 |
| 37 | + end |
| 38 | +
|
| 39 | + subgraph "Internet" |
| 40 | + S3[Server 3<br>External APIs] |
| 41 | + R3[("Remote<br>Resource C")] |
| 42 | +
|
| 43 | + C3 --> S3 |
| 44 | + S3 <--> R3 |
| 45 | + end |
| 46 | +``` |
| 47 | + |
| 48 | +### Host |
| 49 | + |
| 50 | +The host process acts as the container and coordinator: |
| 51 | + |
| 52 | +- Creates and manages multiple client instances |
| 53 | +- Controls client connection permissions and lifecycle |
| 54 | +- Enforces security policies and consent requirements |
| 55 | +- Handles user authorization decisions |
| 56 | +- Coordinates AI/LLM integration and sampling |
| 57 | +- Manages context aggregation across clients |
| 58 | + |
| 59 | +### Clients |
| 60 | + |
| 61 | +Each client is created by the host and maintains an isolated server connection: |
| 62 | + |
| 63 | +- Establishes one stateful session per server |
| 64 | +- Handles protocol negotiation and capability exchange |
| 65 | +- Routes protocol messages bidirectionally |
| 66 | +- Manages subscriptions and notifications |
| 67 | +- Maintains security boundaries between servers |
| 68 | + |
| 69 | +A host application creates and manages multiple clients, with each client having a 1:1 |
| 70 | +relationship with a particular server. |
| 71 | + |
| 72 | +### Servers |
| 73 | + |
| 74 | +Servers provide specialized context and capabilities: |
| 75 | + |
| 76 | +- Expose resources, tools and prompts via MCP primitives |
| 77 | +- Operate independently with focused responsibilities |
| 78 | +- Request sampling through client interfaces |
| 79 | +- Must respect security constraints |
| 80 | +- Can be local processes or remote services |
| 81 | + |
| 82 | +## Design Principles |
| 83 | + |
| 84 | +MCP is built on several key design principles that inform its architecture and |
| 85 | +implementation: |
| 86 | + |
| 87 | +1. **Servers should be extremely easy to build** |
| 88 | + |
| 89 | + - Host applications handle complex orchestration responsibilities |
| 90 | + - Servers focus on specific, well-defined capabilities |
| 91 | + - Simple interfaces minimize implementation overhead |
| 92 | + - Clear separation enables maintainable code |
| 93 | + |
| 94 | +2. **Servers should be highly composable** |
| 95 | + |
| 96 | + - Each server provides focused functionality in isolation |
| 97 | + - Multiple servers can be combined seamlessly |
| 98 | + - Shared protocol enables interoperability |
| 99 | + - Modular design supports extensibility |
| 100 | + |
| 101 | +3. **Servers should not be able to read the whole conversation, nor "see into" other |
| 102 | + servers** |
| 103 | + |
| 104 | + - Servers receive only necessary contextual information |
| 105 | + - Full conversation history stays with the host |
| 106 | + - Each server connection maintains isolation |
| 107 | + - Cross-server interactions are controlled by the host |
| 108 | + - Host process enforces security boundaries |
| 109 | + |
| 110 | +4. **Features can be added to servers and clients progressively** |
| 111 | + - Core protocol provides minimal required functionality |
| 112 | + - Additional capabilities can be negotiated as needed |
| 113 | + - Servers and clients evolve independently |
| 114 | + - Protocol designed for future extensibility |
| 115 | + - Backwards compatibility is maintained |
| 116 | + |
| 117 | +## Capability Negotiation |
| 118 | + |
| 119 | +The Model Context Protocol uses a capability-based negotiation system where clients and |
| 120 | +servers explicitly declare their supported features during initialization. Capabilities |
| 121 | +determine which protocol features and primitives are available during a session. |
| 122 | + |
| 123 | +- Servers declare capabilities like resource subscriptions, tool support, and prompt |
| 124 | + templates |
| 125 | +- Clients declare capabilities like sampling support and notification handling |
| 126 | +- Both parties must respect declared capabilities throughout the session |
| 127 | +- Additional capabilities can be negotiated through extensions to the protocol |
| 128 | + |
| 129 | +```mermaid |
| 130 | +sequenceDiagram |
| 131 | + participant Host |
| 132 | + participant Client |
| 133 | + participant Server |
| 134 | +
|
| 135 | + Host->>+Client: Initialize client |
| 136 | + Client->>+Server: Initialize session with capabilities |
| 137 | + Server-->>Client: Respond with supported capabilities |
| 138 | +
|
| 139 | + Note over Host,Server: Active Session with Negotiated Features |
| 140 | +
|
| 141 | + loop Client Requests |
| 142 | + Host->>Client: User- or model-initiated action |
| 143 | + Client->>Server: Request (tools/resources) |
| 144 | + Server-->>Client: Response |
| 145 | + Client-->>Host: Update UI or respond to model |
| 146 | + end |
| 147 | +
|
| 148 | + loop Server Requests |
| 149 | + Server->>Client: Request (sampling) |
| 150 | + Client->>Host: Forward to AI |
| 151 | + Host-->>Client: AI response |
| 152 | + Client-->>Server: Response |
| 153 | + end |
| 154 | +
|
| 155 | + loop Notifications |
| 156 | + Server--)Client: Resource updates |
| 157 | + Client--)Server: Status changes |
| 158 | + end |
| 159 | +
|
| 160 | + Host->>Client: Terminate |
| 161 | + Client->>-Server: End session |
| 162 | + deactivate Server |
| 163 | +``` |
| 164 | + |
| 165 | +Each capability unlocks specific protocol features for use during the session. For |
| 166 | +example: |
| 167 | + |
| 168 | +- Implemented [server features](/specification/2025-06-18/server) must be advertised in the |
| 169 | + server's capabilities |
| 170 | +- Emitting resource subscription notifications requires the server to declare |
| 171 | + subscription support |
| 172 | +- Tool invocation requires the server to declare tool capabilities |
| 173 | +- [Sampling](/specification/2025-06-18/client) requires the client to declare support in its |
| 174 | + capabilities |
| 175 | + |
| 176 | +This capability negotiation ensures clients and servers have a clear understanding of |
| 177 | +supported functionality while maintaining protocol extensibility. |
0 commit comments