规范
规范
架构

架构

社区译文；来源： MCP 80041ab0

模型上下文协议（Model Context Protocol，简称 MCP）采用客户端-主机-服务器架构，每个主机可以运行多个客户端实例。MCP 是无状态协议：每个请求都是自包含的，并携带自己的协议版本和能力。 这种架构使用户能够跨应用集成 AI 能力，同时保持清晰的安全边界并隔离关注点。MCP 构建于 JSON-RPC 之上，专注于客户端与服务器之间的上下文交换和采样协调。

核心组件 

  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 集成与采样
  • 管理跨客户端的上下文聚合

客户端

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

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

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

服务器

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

  • 通过 MCP 原语公开资源、工具和提示
  • 独立运行并聚焦明确职责
  • 在响应中通过 InputRequiredResult 请求客户端输入（采样（Sampling）、信息征询（Elicitation）、根目录（Roots））
  • 必须遵守安全约束
  • 可以是本地进程或远程服务

设计原则

MCP 建立在若干关键设计原则之上，这些原则指导其架构和实现：

  1. 服务器应该非常容易构建

    • 主机应用负责复杂的编排职责
    • 服务器专注于特定且定义明确的能力
    • 简单接口降低实现开销
    • 清晰分离使代码易于维护

  2. 服务器应该高度可组合

    • 每个服务器独立提供聚焦的功能
    • 多个服务器可以无缝组合
    • 共享协议实现互操作
    • 模块化设计支持扩展

  3. 服务器不应读取整个对话，也不应“看到”其他服务器

    • 服务器只接收必要的上下文信息
    • 完整对话历史保留在主机中
    • 每个服务器保持隔离
    • 跨服务器交互由主机控制
    • 主机进程强制执行安全边界

  4. 可以逐步向服务器和客户端增加功能

    • 核心协议提供最少的必需功能
    • 可按需协商附加能力
    • 服务器和客户端可以独立演进
    • 协议为未来扩展而设计
    • 保持向后兼容性

能力协商

模型上下文协议采用基于能力的协商系统，客户端和服务器在每个请求中声明各自支持的功能。客户端在每个请求的 _meta.io.modelcontextprotocol/clientCapabilities 中包含其能力。服务器通过 server/discover（英文） 响应通告其能力；客户端可以在任何其他请求前调用该方法，以预先发现能力。

  • 服务器声明工具支持、资源订阅和提示模板等能力
  • 客户端声明采样支持和信息征询处理等能力
  • 双方必须在整个交互过程中遵守已声明的能力
  • 可以通过协议扩展协商附加能力
  sequenceDiagram
    participant Host
    participant Client
    participant Server

    opt 发现
        Client->>Server: server/discover
        Server-->>Client: 支持的版本 + 能力
    end

    loop 客户端请求
        Host->>Client: 用户或模型发起的操作
        Client->>Server: 请求（包含 _meta：版本、clientCapabilities）
        alt 服务器需要客户端输入
            Server-->>Client: InputRequiredResult（例如 sampling/createMessage）
            Client->>Host: 转发给 AI
            Host-->>Client: AI 响应
            Client->>Server: 原请求（包含输入）
        end
        Server-->>Client: 响应
        Client-->>Host: 更新 UI 或响应模型
    end

    opt 订阅
        Client->>Server: subscriptions/listen（toolsListChanged、resourceSubscriptions 等）
        Server--)Client: notifications/subscriptions/acknowledged
        loop 流
            Server--)Client: notifications/*（带 subscriptionId）
        end
    end

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

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