> ## Documentation Index
> Fetch the complete documentation index at: https://mcp.developerdoc.cn/llms.txt
> Use this file to discover all available pages before exploring further.

# 架构

<div id="enable-section-numbers" />

Model Context Protocol (MCP) 遵循客户端-宿主-服务器架构，其中每个宿主可以运行多个
客户端实例。MCP 是无状态协议：每个请求都是自包含的，并携带自己的协议版本、客户端身份和能力。
该架构使用户能够跨应用集成 AI 能力，同时保持清晰的安全边界并隔离关注点。MCP 构建在
JSON-RPC 之上，提供一个聚焦于客户端和服务器之间上下文交换与采样协调的协议。

## 核心组件

```mermaid theme={null}
graph LR
    subgraph "Application Host Process"
        H[Host]
        C1[Client 1]
        C2[Client 2]
        C3[Client 3]
        H --> C1
        H --> C2
        H --> C3
    end

    subgraph "Local machine"
        S1[Server 1<br>Files & Git]
        S2[Server 2<br>Database]
        R1[("Local<br>Resource A")]
        R2[("Local<br>Resource B")]

        C1 --> S1
        C2 --> S2
        S1 <--> R1
        S2 <--> R2
    end

    subgraph "Internet"
        S3[Server 3<br>External APIs]
        R3[("Remote<br>Resource C")]

        C3 --> S3
        S3 <--> R3
    end
```

### 宿主

宿主进程充当容器和协调者：

* 创建并管理多个客户端实例
* 控制客户端连接权限和生命周期
* 强制执行安全策略和同意要求
* 处理用户授权决策
* 协调 AI/LLM 集成与采样
* 管理跨客户端的上下文聚合

### 客户端

每个客户端都由宿主创建，并且只与一个服务器通信：

* 只与一个服务器通信
* 为每个请求附加协议版本和能力
* 双向路由协议消息
* 管理订阅和通知
* 维护服务器之间的安全边界

宿主应用创建并管理多个客户端，每个客户端都与特定服务器保持 1:1 关系。

### 服务器

服务器提供专门的上下文和能力：

* 通过 MCP 原语公开资源、工具和提示
* 独立运行，并承担聚焦的职责
* 在回复中通过 `InputRequiredResult` 请求客户端输入（采样、引出、根目录）
* 必须遵守安全约束
* 可以是本地进程或远程服务

## 设计原则

MCP 建立在几个关键设计原则之上，这些原则塑造了它的架构和实现：

1. **服务器应该极易构建**
   * 宿主应用处理复杂的编排职责
   * 服务器聚焦于具体且定义明确的能力
   * 简单接口最大限度降低实现开销
   * 清晰分离带来可维护的代码

2. **服务器应该高度可组合**
   * 每个服务器以隔离方式提供聚焦的功能
   * 多个服务器可以无缝组合
   * 共享协议实现互操作性
   * 模块化设计支持可扩展性

3. **服务器不应能够读取完整对话，也不应能够“看到”其他服务器内部**
   * 服务器只接收必要的上下文信息
   * 完整对话历史保留在宿主中
   * 每个服务器保持隔离
   * 跨服务器交互由宿主控制
   * 宿主进程强制执行安全边界

4. **可以逐步向服务器和客户端添加特性**
   * 核心协议提供最小必需功能
   * 可以根据需要协商额外能力
   * 服务器和客户端独立演进
   * 协议面向未来扩展性而设计
   * 保持向后兼容

## 能力协商

Model Context Protocol 使用基于能力的协商系统，客户端和服务器在每个请求上声明其支持的特性。
客户端在每个请求的 `_meta.io.modelcontextprotocol/clientCapabilities` 中包含其能力。
服务器在响应
[`server/discover`](/specification/draft/server/discover) 时声明其能力，客户端可以在任何其他请求之前调用该方法以预先发现能力。

* 服务器声明工具支持、资源订阅和提示模板等能力
* 客户端声明采样支持和引出处理等能力
* 双方在整个交互过程中都必须遵守已声明的能力
* 可以通过协议扩展协商额外能力

```mermaid theme={null}
sequenceDiagram
    participant Host
    participant Client
    participant Server

    opt Discovery
        Client->>Server: server/discover
        Server-->>Client: supported versions + capabilities
    end

    loop Client Requests
        Host->>Client: User- or model-initiated action
        Client->>Server: Request (with _meta: version, clientInfo, clientCapabilities)
        alt Server requires client input
            Server-->>Client: InputRequiredResult (e.g. sampling/createMessage)
            Client->>Host: Forward to AI
            Host-->>Client: AI response
            Client->>Server: Original request (with input)
        end
        Server-->>Client: Response
        Client-->>Host: Update UI or respond to model
    end

    opt Subscriptions
        Client->>Server: subscriptions/listen (toolsListChanged, resourceSubscriptions, …)
        Server--)Client: notifications/subscriptions/acknowledged
        loop Stream
            Server--)Client: notifications/* (tagged with subscriptionId)
        end
    end
```

每项能力都按请求解锁特定的协议特性。例如：

* 已实现的[服务器特性](/specification/draft/server)必须在服务器能力中声明
* 接收资源更新通知需要打开
  [`subscriptions/listen`](/specification/draft/basic/patterns/subscriptions) 流，并提供所需的资源 URI
* 调用[工具](/specification/draft/server/tools)要求服务器声明工具能力

这种能力协商确保客户端和服务器清楚理解受支持的功能，同时保持协议的可扩展性。