本文整理了MCP的基本協議規范，包括協議架構、協議基本消息類型、協議生命周期管理、協議的傳輸層

1. 協議之架構

1.1 基本組件

1.2 基本消息類型

1.3 能力協商

2. 協議規范之基本消息類型

2.1 Requests（消息請求）

2.2 Responses（消息應答）

2.3 Notifications（通知）

2.4 舉例：Client獲取Server Tool列表

3. 協議規范之生命周期管理

3.1 Initialization（初始化）：

3.2 Operation（操作）

3.3 Shutdown（關閉）

4. 協議規范之傳輸層

5. 參考

整個規范，可以分幾個大塊來了解：協議架構、協議基本消息類型、協議生命周期管理、協議的傳輸層

1. 協議之架構

Model Context Protocol (MCP) 采用 client-host-server 架構，每個 host 可以運行多個client實例。

這種架構使用戶能夠在各個應用程序中集成人工智能能力，同時保持清晰的安全邊界并隔離關注點。

MCP 基于 JSON-RPC 構建，提供了一種有狀態的會話協議，專注于上下文交換和 clients 與servers之間的采樣協調。

JSON-RPC 2.0 規范: ???https://www.jsonrpc.org/specification??

1.1 基本組件

Host

Host進程充當容器和協調者（比如Cline，cursor等）：

• 創建和管理多個客戶端實例
• 控制客戶端連接權限和生命周期
• 協調 AI/LLM 集成和采樣
• 管理Clients之間的上下文聚合

Clients

每個客戶端由Host創建，并保持一個獨立的 server 連接（比如由Cline代碼內嵌的SDK Client）：

• 和每個 server 建立一個有狀態的會話
• 處理協議協商和能力交換
• 雙向路由協議消息
• 管理訂閱和通知
• 維護 servers 之間的安全邊界

host 應用程序創建并管理多個 clients，每個 client 與特定 server 之間具有一對一的關系。

Servers

server 提供專業的上下文和能力：

• 通過 MCP 原語暴露resources、tools 和prompts
• 通過client 提供的接口請求sampling
• 可以是本地進程或遠程服務

1.2 基本消息類型

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

• Requests: 雙向消息，帶有方法和參數，期望有響應
• Responses: 匹配特定請求 ID 的成功結果或錯誤
• Notifications: 無需回復的單向消息

1.3 能力協商

Model Context Protocol 使用了一種基于能力（capability-based）的協商機制，在初始化階段，clients和servers會明確聲明它們支持的功能，而這些能力決定了在會話期間可以使用哪些協議特性和原語（primitives）

2. 協議規范之基本消息類型

所有在 MCP clients 和 servers 之間的消息必須遵循 JSON-RPC 2.0 規范。該協議定義了三種基本類型的消息：

2.1 Requests（消息請求）

??Requests??可以從Client端或者Server端發起

格式要求：

{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

• 請求必須包含一個字符串或整數類型的 ID。
• ID 不能為??null?? 。
• 請求 ID 在同一會話中不得被請求者之前使用過。

2.1.1 Requests的關鍵業務類型：

2.2 Responses（消息應答）

??Responses??是對requests的回復。

格式要求：

{
  jsonrpc: "2.0";
  id: string | number;
  result?: {
    [key: string]: unknown;
  }
  error?: {
    code: number;
    message: string;
    data?: unknown;
  }
}

• Responses 必須包含與其對應 request 相同的 ID。
• 必須設置??result?? 或??error?? 之一。不得同時出現。
• 錯誤代碼必須是整數。

2.3 Notifications（通知）

??Notifications??是從client 發送到server 或反向發送的。不需要回復。

格式要求：

{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

通知不得包含 ID。

2.4 舉例：Client獲取Server Tool列表

要查詢可用的工具，Client發送一個 ??tools/list?? 請求

Request（請求）

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "cursor": "optional-cursor-value"
  }
}

Response（響應）

{
  "jsonrpc": "2.0",
"id": 1,
"result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name or zip code"
            }
          },
          "required": ["location"]
        }
      }
    ],
    "nextCursor": "next-page-cursor"
  }
}

3. 協議規范之生命周期管理

MCP定義了client-server連接的嚴格生命周期，確保了能力協商和狀態管理。

1. Initialization（初始化）: 能力協商和協議版本一致
2. Operation（操作）: 正常的協議通信
3. Shutdown（關閉）: 連接的優雅關閉

3.1 Initialization（初始化）：

初始化階段必須是 client 和 server 之間的第一次交互。在此階段，client 和 server確定協議版本兼容性、交換和協商各自的能力、分享實施細節。

由client 發送一個包含 ??initialize?? 請求來啟動此階段，包含：

• 支持的協議版本
• Client 能力
• Client 信息

{
  "jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "roots": {
        "listChanged": true
      },
      "sampling": {}
    },
    "clientInfo": {
      "name": "ExampleClient",
      "version": "1.0.0"
    }
  }
}

server 必須響應其自身的能力和信息：

{
  "jsonrpc": "2.0",
"id": 1,
"result": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "logging": {},
      "prompts": {
        "listChanged": true
      },
      "resources": {
        "subscribe": true,
        "listChanged": true
      },
      "tools": {
        "listChanged": true
      }
    },
    "serverInfo": {
      "name": "ExampleServer",
      "version": "1.0.0"
    }
  }
}

成功初始化后，client 必須發送一個 ??initialized?? 通知以表明它已準備好開始正常操作：

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

3.1.1 版本協商

在 ??initialize?? 請求中，client 必須發送其支持的協議版本。這應該是client 支持的最新版本。

如果server支持請求的協議版本，則必須以相同的版本進行響應。否則，server必須以其支持的其他協議版本進行響應。這應該是server支持的最新版本。

如果client 不支持server響應中的版本，則應該斷開連接。

3.1.2 能力協商

client 和server 在會話期間將提供哪些可選的協議功能。

關鍵能力包括：

3.2 Operation（操作）

在操作階段，client 和 server 根據協商的能力交換消息。

遵守協商的協議版本

僅使用成功協商的能力

3.3 Shutdown（關閉）

在關閉階段，連接被優雅地終止。

client 發送斷開連接通知

server 關閉連接

清理相關資源

4. 協議規范之傳輸層

MCP 目前定義了兩種標準的 client-server通信傳輸機制：stdio（標準輸入輸出）和基于 SSE 的 HTTP。客戶端應盡可能支持 stdio。

此外，客戶端和服務器也可以以可插拔的方式實現自定義傳輸機制。

5. 參考

??https://spec.modelcontextprotocol.io/specification/2024-11-05/??

本文轉載自??AI取經路??，作者：AI取經路