Skip to main content
已弃用:采样特性自协议版本 2026-07-28 起已弃用 (SEP-2577)。 根据特性生命周期政策,它会在此修订版发布后至少十二个月内保留在规范中,然后才有资格被移除。 新实现 SHOULD NOT 采用它;现有实现 SHOULD 迁移为直接集成 LLM 提供商 API。 参见已弃用特性注册表
Model Context Protocol (MCP) 为服务器通过客户端向语言模型请求 LLM 采样(“补全”或“生成”)提供了标准化方式。该流程允许客户端保持对模型访问、选择和权限的控制,同时让服务器能够利用 AI 能力,而无需服务器 API key。服务器可以请求基于文本、音频或图像的交互,并可选择在提示中包含来自 MCP 服务器的上下文。

用户交互模型

MCP 中的采样允许服务器实现智能体行为,因为它支持在其他 MCP 服务器功能内部_嵌套_发生 LLM 调用。 实现可以自由地通过任何适合自身需求的界面模式公开采样;协议本身并不强制规定任何特定的用户交互模型。
出于信任与安全及安全性考虑,SHOULD 始终让人类参与流程,并能够拒绝采样请求。应用 SHOULD
  • 提供便于直观审查采样请求的 UI
  • 允许用户在发送前查看和编辑提示
  • 在交付前展示生成的响应以供审查

采样中的工具

服务器可以在采样请求中提供 tools 数组以及可选的 toolChoice 配置,要求客户端的 LLM 在采样期间使用工具。tools 数组中的工具定义以该采样请求为作用域,它们不需要对应已注册工具。这使服务器能够实现智能体行为:LLM 可以调用专门指定的工具、接收结果并继续对话,且全部发生在单个采样请求流程内。 客户端 MUST 通过 sampling.tools 能力声明支持工具使用,才能接收启用工具的采样请求。服务器 MUST NOT 向未通过 sampling.tools 能力声明支持工具使用的客户端发送启用工具的采样请求。

能力

支持采样的客户端 MUST 在每个请求的 _meta.io.modelcontextprotocol/clientCapabilities 中声明 sampling 能力: 基本采样:
支持工具使用:
支持上下文包含(已弃用):
includeContext 参数值 "thisServer""allServers" 已根据特性生命周期政策 (SEP-2596) 弃用; 它们最迟会与采样特性本身一起移除。服务器 SHOULD 避免使用这些值 (例如,可以直接省略 includeContext,因为它默认为 "none"),并且除非客户端声明了 sampling.context 能力,否则 SHOULD NOT 使用它们。参见已弃用特性注册表

协议消息

创建消息

为了在处理客户端请求期间请求语言模型生成,服务器会发送包含 sampling/createMessage 请求的 InputRequiredResult 请求:
响应:

使用工具进行采样

下图展示了使用工具进行采样的完整流程,包括多轮工具循环: 为了请求具备工具使用能力的 LLM 生成,服务器会在请求中包含 tools,并可选择包含 toolChoice 请求(服务器 -> 客户端):
响应(客户端 -> 服务器):

多轮工具循环

收到来自 LLM 的工具使用请求后,服务器通常会:
  1. 执行请求的工具使用。
  2. 发送一个附加了工具结果的新采样请求
  3. 接收 LLM 的响应(其中可能包含新的工具使用)
  4. 按需重复多次(服务器可能会限制最大迭代次数,例如在最后一次迭代传入 toolChoice: {mode: "none"},以强制生成最终结果)
带工具结果的后续请求(服务器 -> 客户端):
最终响应(客户端 -> 服务器):

消息内容约束

工具结果消息

当用户消息包含工具结果(type: “tool_result”)时,该消息 MUST 只包含工具结果。不允许在同一条消息中混合工具结果和其他内容类型(文本、图像、音频)。 该约束确保与使用专用角色表示工具结果的提供商 API 兼容(例如 OpenAI 的 “tool” 角色、Gemini 的 “function” 角色)。 有效 - 单个工具结果:
有效 - 多个工具结果:
无效 - 混合内容:

工具使用与结果平衡

在采样中使用工具时,每条包含 ToolUseContent 块的 assistant 消息之后,在任何其他消息之前,MUST 跟随一条完全由 ToolResultContent 块组成的 user 消息,并且每个工具使用(例如带有 id: $id)都要与对应的工具结果(带有 toolUseId: $id)匹配。 此要求确保:
  • 工具使用始终会在对话继续之前得到解析
  • 提供商 API 可以并发处理多个工具使用,并并行获取其结果
  • 对话保持一致的请求-响应模式
有效序列示例:
  1. User 消息:“What’s the weather like in Paris and London?”
  2. Assistant 消息:ToolUseContent (id: "call_abc123", name: "get_weather", input: {city: "Paris"}) + ToolUseContent (id: "call_def456", name: "get_weather", input: {city: "London"})
  3. User 消息:ToolResultContent (toolUseId: "call_abc123", content: "18°C, partly cloudy") + ToolResultContent (toolUseId: "call_def456", content: "15°C, rainy")
  4. Assistant 消息:比较两个城市天气的文本响应
无效序列 - 缺少工具结果:
  1. User 消息:“What’s the weather like in Paris and London?”
  2. Assistant 消息:ToolUseContent (id: "call_abc123", name: "get_weather", input: {city: "Paris"}) + ToolUseContent (id: "call_def456", name: "get_weather", input: {city: "London"})
  3. User 消息:ToolResultContent (toolUseId: "call_abc123", content: "18°C, partly cloudy") ← 缺少 call_def456 的结果
  4. Assistant 消息:文本响应(无效 - 并非所有工具使用都已解析)

跨 API 兼容性

采样规范设计为可跨多个 LLM 提供商 API(Claude、OpenAI、Gemini 等)工作。为实现兼容性的关键设计决策包括:

消息角色

MCP 使用两个角色:“user” 和 “assistant”。 工具使用请求会在 CreateMessageResult 中以 “assistant” 角色发送。工具结果会在带有 “user” 角色的消息中发回。带有工具结果的消息不能包含其他类型的内容。

工具选择模式

CreateMessageRequest.params.toolChoice 控制模型的工具使用能力:
  • {mode: "auto"}:模型决定是否使用工具(默认)
  • {mode: "required"}:模型在完成前 MUST 至少使用一个工具
  • {mode: "none"}:模型 MUST NOT 使用任何工具

并行工具使用

MCP 允许模型并行发出多个工具使用请求(返回 ToolUseContent 数组)。所有主要提供商 API 都支持这一点:
  • Claude:原生支持并行工具使用
  • OpenAI:支持并行工具调用(可通过 parallel_tool_calls: false 禁用)
  • Gemini:原生支持并行函数调用
封装了支持禁用并行工具使用的提供商的实现 MAY 将其作为扩展公开,但这不是 MCP 核心规范的一部分。

消息流

数据类型

Messages

采样消息 MUST 包含值为 "user""assistant"role 字段,以及表示消息数据的 content 字段。 采样请求中的消息列表在不同请求之间 SHOULD NOT 被保留。 content 字段可以包含:

文本内容

图像内容

音频内容

模型偏好

MCP 中的模型选择需要谨慎抽象,因为服务器和客户端可能使用不同的 AI 提供商,而这些提供商提供的模型并不相同。服务器不能简单地按名称请求特定模型,因为客户端可能无法访问该精确模型,或可能更倾向于使用不同提供商的等效模型。 为解决这一问题,MCP 实现了一套偏好系统,将抽象能力优先级与可选模型提示结合起来:

能力优先级

服务器通过三个归一化优先级值(0-1)表达需求:
  • costPriority:最小化成本有多重要?值越高,越偏好更便宜的模型。
  • speedPriority:低延迟有多重要?值越高,越偏好更快的模型。
  • intelligencePriority:高级能力有多重要?值越高,越偏好能力更强的模型。

模型提示

优先级有助于基于特征选择模型,而 hints 允许服务器建议特定模型或模型族:
  • hints 会被视为子字符串,可灵活匹配模型名称
  • 多个 hints 会按偏好顺序评估
  • 客户端 MAY 将 hints 映射到不同提供商的等效模型
  • hints 仅供参考;客户端负责最终模型选择
例如:
客户端会处理这些偏好,从其可用选项中选择合适的模型。例如,如果客户端无法访问 Claude 模型但可以使用 Gemini,它可能会基于相似能力将 sonnet hint 映射到 gemini-1.5-pro

系统提示

可选的 systemPrompt 字段允许服务器请求特定系统提示。客户端 MAY 修改或忽略此字段,而无需告知服务器。

上下文包含

includeContext 参数指定客户端预期在其响应中包含哪些上下文信息:
  • "none":不包含额外上下文。
  • "thisServer":包含来自请求服务器的上下文。
  • "allServers":包含来自所有已连接 MCP 服务器的上下文。
"thisServer""allServers" 值已弃用;见能力 客户端 MAY 修改或忽略此字段,而无需告知服务器。例如,客户端可以判定在某个特定请求中遵循此字段会要求与服务器共享敏感信息,并相应地约束其响应。

采样参数

LLM 采样可以通过以下参数进行微调:
  • temperature:控制模型响应的随机性。值越高,随机性越高;值越低,输出越稳定。有效范围取决于模型提供商。
  • maxTokens:要生成的最大 token 数;必需。
  • stopSequences:停止生成的序列数组。
  • metadata:额外的提供商特定参数。
客户端 MUST 遵守 maxTokens 参数。 客户端 MAY 修改或忽略 temperaturestopSequencesmetadata。例如,客户端可能使用不支持其中一个或多个参数的模型,因此无法利用它们。

结果字段

采样结果将包含以下字段:
  • role:消息角色;见 Messages
  • content:消息内容。它可以是:
    • 当响应仅包含一个内容块(例如单个文本响应)时,为单个内容块。
    • 当响应包含一个或多个内容块(例如多个工具使用或混合内容)时,为内容块数组。
    内容块类型见 Messages
  • model:生成消息的模型名称。
  • stopReason:采样停止的原因(如果已知)。规范定义了以下(非穷尽)停止原因,但实现 MAY 提供自己的任意值:
    • "endTurn":参与方将对话交给另一方。
    • "stopSequence":消息生成遇到了请求的 stopSequences 之一。
    • "maxTokens":已达到 token 限制。
    • "toolUse":模型想要使用一个或多个工具。

错误处理

如果发生错误或用户拒绝采样请求,客户端不需要带着错误消息重放初始调用,因为服务器在 InputRequiredResult 模式下并不会等待响应。

安全注意事项

  1. 客户端 SHOULD 实现用户批准控制
  2. 双方 SHOULD 验证消息内容
  3. 客户端 SHOULD 尊重模型偏好 hints
  4. 客户端 SHOULD 实现速率限制
  5. 双方 MUST 适当处理敏感数据
在采样中使用工具时,还适用以下额外安全注意事项:
  1. 服务器 MUST 确保在回复 stopReason: "toolUse" 时,每个 ToolUseContent 项都有一个带匹配 toolUseIdToolResultContent 项作为响应,并且 user 消息只包含工具结果(不包含其他内容类型)
  2. 双方 SHOULD 为工具循环实现迭代限制