採樣

模型上下文協議 (MCP) 為服務器提供了通過客戶端從語言模型請求 LLM 採樣（“補全"或"生成”）的標準化方式。這種流程允許客戶端保持對模型訪問、選擇和權限的控制，同時使服務器能夠利用 AI 能力——無需服務器 API 密鑰。服務器可以請求基於文本、音頻或圖像的交互，並可以選擇在其提示中包含來自 MCP 服務器的上下文。

用戶交互模型

MCP 中的採樣允許服務器實現智能行為，通過使 LLM 調用可以在其他 MCP 服務器功能中_嵌套_發生。

實現可以通過任何適合其需求的界面模式公開採樣——協議本身不強制任何特定的用戶交互模型。

能力

支持採樣的客戶端必須在初始化期間聲明 sampling 能力：

{
  "capabilities": {
    "sampling": {}
  }
}

協議消息

創建消息

要請求語言模型生成，服務器發送 sampling/createMessage 請求：

請求：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "法國的首都是什麼？"
        }
      }
    ],
    "modelPreferences": {
      "hints": [
        {
          "name": "claude-3-sonnet"
        }
      ],
      "intelligencePriority": 0.8,
      "speedPriority": 0.5
    },
    "systemPrompt": "你是一個有幫助的助手。",
    "maxTokens": 100
  }
}

響應：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "role": "assistant",
    "content": {
      "type": "text",
      "text": "法國的首都是巴黎。"
    },
    "model": "claude-3-sonnet-20240307",
    "stopReason": "endTurn"
  }
}

消息流

  sequenceDiagram
    participant Server
    participant Client
    participant User
    participant LLM

    Note over Server,Client: 服務器啟動採樣
    Server->>Client: sampling/createMessage

    Note over Client,User: 人在循環中審查
    Client->>User: 提交請求供批准
    User-->>Client: 審查並批准/修改

    Note over Client,LLM: 模型交互
    Client->>LLM: 轉發批准的請求
    LLM-->>Client: 返回生成內容

    Note over Client,User: 響應審查
    Client->>User: 提交響應供批准
    User-->>Client: 審查並批准/修改

    Note over Server,Client: 完成請求
    Client-->>Server: 返回批准的響應

數據類型

消息

採樣消息可以包含：

文本內容

{
  "type": "text",
  "text": "消息內容"
}

圖像內容

{
  "type": "image",
  "data": "base64編碼的圖像數據",
  "mimeType": "image/jpeg"
}

音頻內容

{
  "type": "audio",
  "data": "base64編碼的音頻數據",
  "mimeType": "audio/wav"
}

模型偏好

MCP 中的模型選擇需要仔細抽象，因為服務器和客戶端可能使用具有不同模型產品的不同 AI 提供商。服務器不能簡單地按名稱請求特定模型，因為客戶端可能無法訪問該確切模型，或者可能更喜歡使用不同提供商的等效模型。

為了解決這個問題，MCP 實現了一個結合抽象能力優先級和可選模型提示的偏好系統：

能力優先級

服務器通過三個歸一化的優先級值（0-1）表達其需求：

• costPriority：減少成本有多重要？較高的值偏好更便宜的模型。
• speedPriority：低延遲有多重要？較高的值偏好更快的模型。
• intelligencePriority：高級能力有多重要？較高的值偏好更強大的模型。

模型提示

雖然優先級有助於根據特性選擇模型，但 hints 允許服務器建議特定的模型或模型系列：

• 提示被視為可以靈活匹配模型名稱的子字符串
• 多個提示按優先順序評估
• 客戶端可以將提示映射到不同提供商的等效模型
• 提示是建議性的——客戶端做出最終模型選擇

例如：

{
  "hints": [
    { "name": "claude-3-sonnet" }, // 首選 Sonnet 類模型
    { "name": "claude" } // 備選任何 Claude 模型
  ],
  "costPriority": 0.3, // 成本不太重要
  "speedPriority": 0.8, // 速度非常重要
  "intelligencePriority": 0.5 // 中等能力需求
}

客戶端處理這些偏好，從其可用選項中選擇適當的模型。例如，如果客戶端沒有訪問 Claude 模型的權限，但有 Gemini，它可能會基於類似的能力將 sonnet 提示映射到 gemini-1.5-pro。

錯誤處理

客戶端應該為常見故障情況返回錯誤：

錯誤示例：

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -1,
    "message": "用戶拒絕了採樣請求"
  }
}

安全考慮

1. 客戶端應該實現用戶批准控制
2. 雙方應該驗證消息內容
3. 客戶端應該尊重模型偏好提示
4. 客戶端應該實現速率限制
5. 雙方必須適當處理敏感數據