通訊協議

MCP 定義了一個標準化的通訊協議，使客戶端和伺服器能夠以一致、可預測的方式交換訊息。這種標準化對於整個社群的互操作性至關重要。在本節中，我們將探討 MCP 中使用的協議結構和傳輸機制。

JSON-RPC：基礎

MCP 的核心是使用 JSON-RPC 2.0 作為客戶端和伺服器之間所有通訊的訊息格式。JSON-RPC 是一種輕量級的遠端過程呼叫協議，採用 JSON 編碼，這使得它：

• 可讀性強，易於除錯
• 語言無關，支援在任何程式設計環境中實現
• 成熟穩定，規範清晰，應用廣泛

該協議定義了三種類型的訊息

1. 請求

從客戶端傳送到伺服器以發起操作。請求訊息包括：

• 唯一識別符號（id）
• 要呼叫的方法名稱（例如，tools/call）
• 方法的引數（如果有）

請求示例

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "weather",
    "arguments": {
      "location": "San Francisco"
    }
  }
}

2. 響應

伺服器響應請求傳送到客戶端。響應訊息包括：

• 與相應請求相同的 id
• result（成功）或 error（失敗）

成功響應示例

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "temperature": 62,
    "conditions": "Partly cloudy"
  }
}

錯誤響應示例

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "Invalid location parameter"
  }
}

3. 通知

不需要響應的單向訊息。通常從伺服器傳送到客戶端，以提供有關事件的更新或通知。

通知示例

{
  "jsonrpc": "2.0",
  "method": "progress",
  "params": {
    "message": "Processing data...",
    "percent": 50
  }
}

傳輸機制

JSON-RPC 定義了訊息格式，但 MCP 還規定了這些訊息如何在客戶端和伺服器之間傳輸。支援兩種主要的傳輸機制：

stdio（標準輸入/輸出）

stdio 傳輸用於本地通訊，其中客戶端和伺服器在同一臺機器上執行

宿主應用程式將伺服器作為子程序啟動，並透過向其標準輸入 (stdin) 寫入和從其標準輸出 (stdout) 讀取來與其通訊。

此傳輸的主要優點是它簡單，無需網路配置，並透過作業系統安全沙盒。

HTTP + SSE（伺服器傳送事件）/可流式 HTTP

HTTP+SSE 傳輸用於遠端通訊，其中客戶端和伺服器可能位於不同的機器上

通訊透過 HTTP 進行，伺服器使用伺服器傳送事件 (SSE) 透過持久連線將更新推送到客戶端。

此傳輸的主要優點是它可以在網路上工作，實現與 Web 服務的整合，並與無伺服器環境相容。

MCP 標準的最新更新引入或完善了“可流式 HTTP”，它透過允許伺服器在需要時動態升級到 SSE 進行流式傳輸，同時保持與無伺服器環境的相容性，從而提供了更大的靈活性。

互動生命週期

在上一節中，我們討論了客戶端 (💻) 和伺服器 (🌐) 之間單個互動的生命週期。現在我們來看看 MCP 協議上下文中客戶端和伺服器之間完整互動的生命週期。

MCP 協議定義了客戶端和伺服器之間結構化的互動生命週期

初始化

客戶端連線到伺服器，它們交換協議版本和功能，伺服器響應其支援的協議版本和功能。

客戶端透過通知訊息確認初始化完成。

發現

客戶端請求有關可用功能的資訊，伺服器響應可用工具列表。

此過程可以針對每個工具、資源或提示型別重複。

執行

客戶端根據宿主的需求呼叫功能。

終止

不再需要時，連線會正常關閉，伺服器確認關閉請求。

客戶端傳送最終退出訊息以完成終止。

協議演進

MCP 協議旨在可擴充套件和適應。初始化階段包括版本協商，允許協議演進時向後相容。此外，功能發現使客戶端能夠適應每個伺服器提供的特定功能，從而在同一生態系統中實現基本和高階伺服器的混合。