信息收集(Elicitation)是在此版本的 MCP 规范中新引入的,其设计可能会在未来的协议版本中演变。
用户交互模型
MCP 中的信息收集允许服务器通过启用用户输入请求发生在其他 MCP 服务器功能_内部_来实现交互式工作流。 实现可以自由暴露信息收集功能,通过任何适合其需求的界面模式——协议本身不强制任何特定的用户交互模型。能力
支持信息收集的客户端必须在 初始化 期间声明elicitation 能力:
协议消息
创建信息收集请求
要向用户请求信息,服务器发送一个elicitation/create 请求:
简单文本请求
请求:结构化数据请求
请求:消息流程
请求 Schema
requestedSchema 字段允许服务器使用 JSON Schema 的受限子集来定义预期响应的结构。为了简化客户端的实现,信息收集 Schema 仅限于具有原始属性的扁平对象:
支持的 Schema 类型
Schema 限制为以下原始类型:-
字符串 Schema
支持的格式:
email,uri,date,date-time -
数字 Schema
-
布尔值 Schema
-
枚举 Schema
- 生成适当的输入表单
- 在发送前验证用户输入
- 为用户提供更好的指导
响应动作
信息收集响应使用三动作模型来清楚区分不同的用户动作:-
接受 (
action: "accept"):用户明确批准并提交数据content字段包含与请求的 Schema 匹配的提交数据- 示例:用户点击了 “Submit”, “OK”, “Confirm” 等
-
拒绝 (
action: "decline"):用户明确拒绝请求content字段通常被省略- 示例:用户点击了 “Reject”, “Decline”, “No” 等
-
取消 (
action: "cancel"):用户解散而未做出明确选择content字段通常被省略- 示例:用户关闭了对话框、点击外部、按 Escape 键等
- 接受:处理提交的数据
- 拒绝:处理明确拒绝(例如,提供替代方案)
- 取消:处理解散(例如,稍后再次提示)
安全考虑
- 服务器不得通过信息收集请求敏感信息
- 客户端应该实现用户批准控制
- 双方应该根据提供的 Schema 验证信息收集内容
- 客户端应该提供明确指示哪个服务器正在请求信息
- 客户端应该允许用户随时拒绝信息收集请求
- 客户端应该实施速率限制
- 客户端应该以清楚表明正在请求什么信息以及为何请求的方式呈现信息收集请求