規範
規範（2024-11-05）
架構

架構

模型上下文協議（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<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 原語公開資源、工具和提示
  • 獨立運行，具有專注的職責
  • 通過客戶端接口請求採樣
  • 必須尊重安全約束
  • 可以是本地進程或遠程服務

設計原則

MCP 基於幾個關鍵設計原則，這些原則指導其架構和實現：

  1. 服務器應該非常容易構建

    • 宿主應用程序處理複雜的編排職責
    • 服務器專注於特定的、明確定義的功能
    • 簡單的接口最小化實現開銷
    • 清晰的分離使代碼可維護

  2. 服務器應該高度可組合

    • 每個服務器在隔離中提供專注的功能
    • 多個服務器可以無縫組合
    • 共享協議實現互操作性
    • 模塊化設計支持可擴展性

  3. 服務器不應該能夠讀取整個對話，也不應"看到"其他服務器

    • 服務器只接收必要的上下文信息
    • 完整的對話歷史保留在宿主
    • 每個服務器連接保持隔離
    • 跨服務器交互由宿主控制
    • 宿主進程執行安全邊界

  4. 可以逐步向服務器和客戶端添加功能

    • 核心協議提供最小的必需功能
    • 根據需要可以協商額外的功能
    • 服務器和客戶端獨立演化
    • 協議為未來擴展性而設計
    • 保持向後兼容性

消息類型

MCP 基於 JSON-RPC 2.0 定義了三種核心消息類型：

  • 請求：雙向消息，具有期待響應的方法和參數
  • 響應：匹配特定請求 ID 的成功結果或錯誤
  • 通知：不需要響應的單向消息

每種消息類型遵循 JSON-RPC 2.0 規範的結構和傳遞語義。

能力協商

模型上下文協議使用基於能力的協商系統，客戶端和服務器在初始化期間明確聲明它們支持的功能。能力決定了會話期間可用的協議功能和原語。

  • 服務器聲明資源訂閱、工具支持和提示模板等能力
  • 客戶端聲明採樣支持和通知處理等能力
  • 雙方必須在整個會話期間尊重聲明的能力
  • 可以通過協議擴展協商額外的能力
  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

每個能力在會話期間解鎖特定的協議功能。例如：

  • 已實現的服務器功能必須在服務器的能力中公告
  • 發出資源訂閱通知需要服務器聲明訂閱支持
  • 工具調用需要服務器聲明工具能力
  • 採樣需要客戶端在其能力中聲明支持

這種能力協商確保客戶端和服務器對支持的功能有清晰的理解，同時保持協議的可擴展性。