规范
架构

架构

Model Context Protocol (MCP) 遵循客户端-主机-服务器架构，每个主机可以运行多个客户端实例。此架构使用户能够在应用程序中集成 AI 功能，同时保持明确的安全边界和隔离关注点。基于 JSON-RPC，MCP 提供了一个有状态的会话协议，专注于上下文交换和客户端与服务器之间的采样协调。

核心组件 

graph LR
    subgraph "应用主机进程"
        H[主机]
        C1[客户端 1]
        C2[客户端 2]
        C3[客户端 3]
        H --> C1
        H --> C2
        H --> C3
    end

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

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

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

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

主机

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

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

客户端

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

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

主机应用程序创建和管理多个客户端，每个客户端与特定服务器具有 1:1 关系。

服务器

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

  • 通过 MCP 原语公开资源、工具和提示
  • 独立运行，具有明确的职责
  • 通过客户端接口请求采样
  • 必须遵守安全约束
  • 可以是本地进程或远程服务

设计原则

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

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

    • 主机应用程序处理复杂的编排职责
    • 服务器专注于特定的、明确的功能
    • 简单的接口最小化实现开销
    • 明确的分离使代码易于维护

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

    • 每个服务器在隔离中提供专注的功能
    • 多个服务器可以无缝组合
    • 共享协议实现互操作性
    • 模块化设计支持可扩展性

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

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

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

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

消息类型

MCP 定义了基于 JSON-RPC 2.0 的三种核心消息类型：

  • 请求: 带有方法和参数的双向消息，期望响应
  • 响应: 匹配特定请求 ID 的成功结果或错误
  • 通知: 不需要响应的单向消息

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

功能协商

Model Context Protocol 使用基于功能的协商系统，客户端和服务器在初始化期间明确声明其支持的功能。功能确定会话期间可用的协议功能和原语。

  • 服务器声明资源订阅、工具支持和提示模板等功能
  • 客户端声明采样支持和通知处理等功能
  • 双方必须在整个会话期间尊重声明的功能
  • 可以通过协议扩展协商额外的功能
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

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

  • 实现的 服务器功能 必须在服务器的功能中声明
  • 发出资源订阅通知需要服务器声明订阅支持
  • 工具调用需要服务器声明工具功能
  • 采样 需要客户端在其功能中声明支持

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