采样

模型上下文协议 (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. 双方必须适当处理敏感数据