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