協定規範

Model Context Protocol 的詳細技術規範

協定概述

模型上下文協定 (MCP) 遵循客戶端-主機-伺服器架構，其中每個主機可以執行多個客戶端實例。該架構讓使用者能夠跨應用程式整合 AI 能力，同時保持清晰的安全邊界並隔離問題。MCP 基於 JSON-RPC 構建，提供了一個有狀態的會話協定，專注於客戶端和伺服器之間的上下文交換和採樣協調。

架構

核心元件架構如下所示：

元件詳情

主機

主機進程是 MCP 協定的核心協調者。它負責管理客戶端實例的生命週期，控制連線權限，並執行安全策略。主機還負責協調 AI/LLM 整合，確保整個系統的平穩運作。

管理客戶端實例的生命週期

控制連線權限和執行安全策略

協調 AI/LLM 整合

確保系統穩定運作

客戶端

客戶端由主機建立，用於維護與伺服器的獨立連線。每個客戶端都與一個伺服器保持 1:1 的關係，確保連線的隔離性和安全性。

維護與伺服器的獨立連線

建立有狀態的會話

處理協定協商

管理訊息路由

伺服器

伺服器負責公開資源和工具，可以獨立執行並通過客戶端請求採樣。伺服器可以是本地的也可以是遠端的，為系統提供各種功能。

公開特定的資源和工具

獨立執行和管理

通過客戶端處理請求

支援本地和遠端服務

協定基礎

MCP 中的所有訊息必須遵循 JSON-RPC 2.0 規範。協定定義了三種類型的訊息：

請求

雙向訊息，可以從客戶端發送到伺服器，也可以反向發送

必須包含字串或整數類型的 ID

ID 不能為 null

在同一會話中，請求方不能重複使用相同的 ID

可以包含可選的參數物件

請求範例

{
  "jsonrpc": "2.0",
  "id": "string | number",
  "method": "string",
  "param?": {
    "key": "value"
  }
}

回應

作為對請求的回覆而發送

必須包含與對應請求相同的 ID

必須設定 result 或 error 其中之一，不能同時設定

錯誤碼必須是整數

可以包含可選的結果資料

回應範例

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

通知

不需要回應的單向訊息，可以從客戶端發送到伺服器，也可以反向發送

不能包含 ID 欄位

用於狀態更新和事件通知

可以包含可選的參數物件

減少通訊開銷，支援非同步操作

通知範例

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

生命週期

MCP 為客戶端與伺服器連線定義了嚴謹的生命週期，確保正確的能力協商與狀態管理。

初始化階段

初始化階段必須是客戶端與伺服器之間的第一次互動。在此階段，雙方：

建立協定版本相容性

交換與協商能力

共享實作細節

初始化請求

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

初始化回應

{
  "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"
    }
  }
}

初始化完成通知

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

版本協商

在初始化請求中，客戶端必須發送其支援的協定版本。

客戶端應發送其支援的最新版本

伺服器必須回應相同版本或其支援的其他版本

若客戶端不支援伺服器的版本，應斷開連線

能力協商

客戶端與伺服器能力決定會話期間可用的選用協定功能。

客戶端能力

roots

提供檔案系統根目錄的能力

sampling

支援 LLM 取樣請求

experimental

描述對非標準實驗性功能的支援

伺服器能力

prompts

提供提示範本

resources

提供可讀資源

tools

提供可呼叫工具

logging

發出結構化日誌訊息

experimental

描述對非標準實驗性功能的支援

操作階段

在操作階段，客戶端與伺服器根據協商的能力交換訊息。

遵守協商的協定版本

僅使用成功協商的能力

關閉階段

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

客戶端發送斷開連線通知

伺服器關閉連線

清理相關資源

傳輸機制

MCP 目前定義了兩種標準的客戶端-伺服器通訊傳輸機制：stdio（標準輸入輸出）與基於 SSE 的 HTTP。客戶端應盡可能支援 stdio。此外，客戶端與伺服器也可以以可插拔的方式實作自訂傳輸機制。

標準輸入輸出（stdio）

在 stdio 傳輸機制中：

客戶端將 MCP 伺服器作為子程序啟動
伺服器透過標準輸入（stdin）接收 JSON-RPC 訊息，並透過標準輸出（stdout）寫入回應
訊息以換行符分隔，且不能包含嵌入的換行符
伺服器可以將 UTF-8 字串寫入標準錯誤（stderr）用於日誌記錄。客戶端可以擷取、轉發或忽略這些日誌
伺服器不能向標準輸出寫入任何非有效 MCP 訊息的內容
客戶端不能向伺服器的標準輸入寫入任何非有效 MCP 訊息的內容

基於 SSE 的 HTTP

在 SSE 傳輸機制中，伺服器作為獨立程序執行，可以處理多個客戶端連線。

伺服器必須提供兩個端點：

SSE 端點 - 用於客戶端建立連線並接收來自伺服器的訊息
HTTP POST 端點 - 用於客戶端向伺服器發送訊息

當客戶端連線時，伺服器必須發送一個包含客戶端用於發送訊息的 URI 的 endpoint 事件
所有後續的客戶端訊息必須作為 HTTP POST 請求發送到此端點
伺服器訊息作為 SSE message 事件發送，訊息內容以 JSON 格式編碼在事件資料中

自訂傳輸機制

客戶端與伺服器可以實作額外的自訂傳輸機制以滿足其特定需求。協定與傳輸機制無關，可以在任何支援雙向訊息交換的通訊通道上實作。

選擇支援自訂傳輸機制的實作者必須確保保留 MCP 定義的 JSON-RPC 訊息格式與生命週期要求
自訂傳輸機制應該記錄其特定的連線建立與訊息交換模式，以幫助實現互通性

伺服器功能

伺服器提供了透過 MCP 將上下文添加到語言模型的基本構建塊，提供了三個基本原語來管理上下文：提示詞、資源和工具。

原語	控制	描述	範例
提示詞	系統	定義模型的行為和角色	你是一個專業的程式碼審查者
資源	用戶	提供額外的上下文資訊	程式碼文件、文件
工具	系統/用戶	擴展模型的能力	程式碼搜索、文件編輯

資源管理

為AI模型提供上下文和資料

支持多種資源類型
動態資源加載
資源生命週期管理

工具集成

擴展AI模型的能力範圍

靈活的工具註冊機制
工具調用權限控制
異步工具執行支持

上下文控制

精確控制AI模型的行為

系統級提示詞管理
動態上下文更新
多輪對話狀態維護