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

# 架构

模型上下文协议（MCP）采用客户端-宿主-服务器架构，其中每个宿主可以运行多个客户端实例。这种架构使用户能够在应用程序之间集成AI能力，同时保持清晰的安全边界并隔离关注点。MCP基于JSON-RPC构建，提供了一种有状态的会话协议，专注于客户端与服务器之间的上下文交换和采样协调。

## 核心组件

```mermaid theme={null}
graph LR
    subgraph "应用宿主进程"
        H[宿主]
        C1[客户端 1]
        C2[客户端 2]
        C3[客户端 3]
        H --> C1
        H --> C2
        H --> C3
    end

    subgraph "本地机器"
        S1[服务器 1<br>文件 & Git]
        S2[服务器 2<br>数据库]
        R1[("本地<br>资源 A")]
        R2[("本地<br>资源 B")]

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

    subgraph "互联网"
        S3[服务器 3<br>外部API]
        R3[("远程<br>资源 C")]

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

### 宿主

宿主进程作为容器和协调者：

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

### 客户端

每个客户端由宿主创建，并维护一个隔离的服务器连接：

* 每个服务器建立一个有状态的会话
* 处理协议协商和能力交换
* 双向路由协议消息
* 管理订阅和通知
* 在服务器之间维护安全边界

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

### 服务器

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

* 通过MCP原语暴露资源、工具和提示
* 独立运行并承担明确职责
* 通过客户端接口请求采样
* 必须遵守安全限制
* 可以是本地进程或远程服务

## 设计原则

MCP基于若干关键设计原则，这些原则指导其架构和实现：

1. **服务器应极其易于构建**
   * 宿主应用处理复杂的编排职责
   * 服务器专注于特定、明确定义的能力
   * 简单接口最小化实现开销
   * 明确的分离使得代码易于维护

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

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

4. **功能可以逐步添加到服务器和客户端**
   * 核心协议提供最低限度的必需功能
   * 可根据需要协商额外能力
   * 服务器和客户端独立演进
   * 协议设计考虑未来扩展性
   * 维持向后兼容性

## 消息类型

MCP定义了三种核心消息类型，基于[JSON-RPC 2.0](https://www.jsonrpc.org/specification)：

* **请求**：具有方法和参数并期望响应的双向消息
* **响应**：匹配特定请求ID的成功结果或错误
* **通知**：无需响应的单向消息

每种消息类型都遵循JSON-RPC 2.0规范的结构和传输语义。

## 能力协商

模型上下文协议使用基于能力的协商系统，客户端和服务器在初始化期间显式声明其支持的功能。能力决定了会话期间可用的协议特性和原语。

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

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

    Host->>+Client: 初始化客户端
    Client->>+Server: 用能力初始化会话
    Server-->>Client: 响应支持的能力

    Note over Host,Server: 使用协商功能的活动会话

    loop 客户端请求
        Host->>Client: 用户或模型发起的动作
        Client->>Server: 请求（工具/资源）
        Server-->>Client: 响应
        Client-->>Host: 更新UI或响应模型
    end

    loop 服务器请求
        Server->>Client: 请求（采样）
        Client->>Host: 转发给AI
        Host-->>Client: AI响应
        Client-->>Server: 响应
    end

    loop 通知
        Server--)Client: 资源更新
        Client--)Server: 状态变更
    end

    Host->>Client: 终止
    Client->>-Server: 结束会话
    deactivate Server
```

每种能力都会解锁会话期间可使用的特定协议功能。例如：

* [服务器功能](/specification/2024-11-05/server)必须在服务器能力中声明
* 发送资源订阅通知要求服务器声明订阅支持
* 工具调用要求服务器声明工具能力
* [采样](/specification/2024-11-05/client)要求客户端在能力中声明支持

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