本文整理了MCP的基本協(xié)議規(guī)范，包括協(xié)議架構(gòu)、協(xié)議基本消息類型、協(xié)議生命周期管理、協(xié)議的傳輸層

1. 協(xié)議之架構(gòu)

1.1 基本組件

1.2 基本消息類型

1.3 能力協(xié)商

2. 協(xié)議規(guī)范之基本消息類型

2.1 Requests（消息請求）

2.2 Responses（消息應(yīng)答）

2.3 Notifications（通知）

2.4 舉例：Client獲取Server Tool列表

3. 協(xié)議規(guī)范之生命周期管理

3.1 Initialization（初始化）：

3.2 Operation（操作）

3.3 Shutdown（關(guān)閉）

4. 協(xié)議規(guī)范之傳輸層

5. 參考

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

1. 協(xié)議之架構(gòu)

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

這種架構(gòu)使用戶能夠在各個應(yīng)用程序中集成人工智能能力，同時保持清晰的安全邊界并隔離關(guān)注點。

MCP 基于 JSON-RPC 構(gòu)建，提供了一種有狀態(tài)的會話協(xié)議，專注于上下文交換和 clients 與servers之間的采樣協(xié)調(diào)。

JSON-RPC 2.0 規(guī)范: ???https://www.jsonrpc.org/specification??

1.1 基本組件

Host

Host進程充當(dāng)容器和協(xié)調(diào)者（比如Cline，cursor等）：

• 創(chuàng)建和管理多個客戶端實例
• 控制客戶端連接權(quán)限和生命周期
• 協(xié)調(diào) AI/LLM 集成和采樣
• 管理Clients之間的上下文聚合

Clients

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

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

host 應(yīng)用程序創(chuàng)建并管理多個 clients，每個 client 與特定 server 之間具有一對一的關(guān)系。

Servers

server 提供專業(yè)的上下文和能力：

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

1.2 基本消息類型

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

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

1.3 能力協(xié)商

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

2. 協(xié)議規(guī)范之基本消息類型

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

2.1 Requests（消息請求）

??Requests??可以從Client端或者Server端發(fā)起

格式要求：

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

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

2.1.1 Requests的關(guān)鍵業(yè)務(wù)類型：

2.2 Responses（消息應(yīng)答）

??Responses??是對requests的回復(fù)。

格式要求：

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

• Responses 必須包含與其對應(yīng) request 相同的 ID。
• 必須設(shè)置??result?? 或??error?? 之一。不得同時出現(xiàn)。
• 錯誤代碼必須是整數(shù)。

2.3 Notifications（通知）

??Notifications??是從client 發(fā)送到server 或反向發(fā)送的。不需要回復(fù)。

格式要求：

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

通知不得包含 ID。

2.4 舉例：Client獲取Server Tool列表

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

Request（請求）

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

Response（響應(yīng)）

{
  "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. 協(xié)議規(guī)范之生命周期管理

MCP定義了client-server連接的嚴(yán)格生命周期，確保了能力協(xié)商和狀態(tài)管理。

1. Initialization（初始化）: 能力協(xié)商和協(xié)議版本一致
2. Operation（操作）: 正常的協(xié)議通信
3. Shutdown（關(guān)閉）: 連接的優(yōu)雅關(guān)閉

3.1 Initialization（初始化）：

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

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

• 支持的協(xié)議版本
• 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 必須響應(yīng)其自身的能力和信息：

{
  "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 必須發(fā)送一個 ??initialized?? 通知以表明它已準(zhǔn)備好開始正常操作：

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

3.1.1 版本協(xié)商

在 ??initialize?? 請求中，client 必須發(fā)送其支持的協(xié)議版本。這應(yīng)該是client 支持的最新版本。

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

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

3.1.2 能力協(xié)商

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

關(guān)鍵能力包括：

3.2 Operation（操作）

在操作階段，client 和 server 根據(jù)協(xié)商的能力交換消息。

遵守協(xié)商的協(xié)議版本

僅使用成功協(xié)商的能力

3.3 Shutdown（關(guān)閉）

在關(guān)閉階段，連接被優(yōu)雅地終止。

client 發(fā)送斷開連接通知

server 關(guān)閉連接

清理相關(guān)資源

4. 協(xié)議規(guī)范之傳輸層

MCP 目前定義了兩種標(biāo)準(zhǔn)的 client-server通信傳輸機制：stdio（標(biāo)準(zhǔn)輸入輸出）和基于 SSE 的 HTTP?？蛻舳藨?yīng)盡可能支持 stdio。

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

5. 參考

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

本文轉(zhuǎn)載自??AI取經(jīng)路??，作者：AI取經(jīng)路