信息征求（Elicitation）是此版 MCP 规范中新引入的功能，其设计可能会在未来的协议版本中演变。
用户交互模型
MCP 中的信息征求功能允许服务器通过在其他 MCP 服务器功能中嵌套用户输入请求来实现交互式工作流。 实现时可以自由地通过任何适合其需求的接口模式来暴露信息征求功能——协议本身并不强制要求任何特定的用户交互模型。为了信任、安全与保障应用程序**应该**
- 提供清晰的 UI，指明是哪个服务器在请求信息
- 允许用户在发送前审查和修改他们的响应
- 尊重用户隐私，并提供明确的拒绝和取消选项
elicitation 能力
{
"capabilities": {
"elicitation": {}
}
}
协议消息
创建信息征求请求
要向用户请求信息，服务器需发送一个 elicitation/create 请求
简单文本请求
请求
{
"jsonrpc": "2.0",
"id": 1,
"method": "elicitation/create",
"params": {
"message": "Please provide your GitHub username",
"requestedSchema": {
"type": "object",
"properties": {
"name": {
"type": "string"
}
},
"required": ["name"]
}
}
}
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"action": "accept",
"content": {
"name": "octocat"
}
}
}
结构化数据请求
请求
{
"jsonrpc": "2.0",
"id": 2,
"method": "elicitation/create",
"params": {
"message": "Please provide your contact information",
"requestedSchema": {
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Your full name"
},
"email": {
"type": "string",
"format": "email",
"description": "Your email address"
},
"age": {
"type": "number",
"minimum": 18,
"description": "Your age"
}
},
"required": ["name", "email"]
}
}
}
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"action": "accept",
"content": {
"name": "Monalisa Octocat",
"email": "[email protected]",
"age": 30
}
}
}
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"action": "decline"
}
}
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"action": "cancel"
}
}
消息流
请求模式
requestedSchema 字段允许服务器使用 JSON Schema 的一个受限子集来定义预期响应的结构。为简化客户端的实现，信息征求模式仅限于只有基本类型属性的扁平对象
"requestedSchema": {
"type": "object",
"properties": {
"propertyName": {
"type": "string",
"title": "Display Name",
"description": "Description of the property"
},
"anotherProperty": {
"type": "number",
"minimum": 0,
"maximum": 100
}
},
"required": ["propertyName"]
}
支持的模式类型
该模式仅限于以下基本类型
-
字符串模式
{
"type": "string",
"title": "Display Name",
"description": "Description text",
"minLength": 3,
"maxLength": 50,
"format": "email" // Supported: "email", "uri", "date", "date-time"
}
email、uri、date、date-time
-
数字模式
{
"type": "number", // or "integer"
"title": "Display Name",
"description": "Description text",
"minimum": 0,
"maximum": 100
}
-
布尔值模式
{
"type": "boolean",
"title": "Display Name",
"description": "Description text",
"default": false
}
-
枚举模式
{
"type": "string",
"title": "Display Name",
"description": "Description text",
"enum": ["option1", "option2", "option3"],
"enumNames": ["Option 1", "Option 2", "Option 3"]
}
客户端可以使用此模式来
- 生成适当的输入表单
- 在发送前验证用户输入
- 为用户提供更好的引导
请注意，为了简化客户端的实现，有意不支持复杂的嵌套结构、对象数组以及其他高级 JSON Schema 功能。
响应操作
信息征求响应使用三操作模型，以清晰地区分不同的用户行为
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"action": "accept", // or "decline" or "cancel"
"content": {
"propertyName": "value",
"anotherProperty": 42
}
}
}
-
接受 (
action: "accept")：用户明确批准并提交了数据
content 字段包含与所请求模式匹配的已提交数据- 示例：用户点击了“提交”、“确定”、“确认”等。
-
拒绝 (
action: "decline")：用户明确拒绝了该请求
content 字段通常被省略- 示例：用户点击了“拒绝”、“不同意”、“否”等。
-
取消 (
action: "cancel")：用户未做明确选择便关闭了请求
content 字段通常被省略- 示例：用户关闭了对话框、点击了对话框外部、按下了 Escape 键等。
服务器应恰当地处理每种状态
- 接受：处理提交的数据
- 拒绝：处理明确的拒绝（例如，提供替代方案）
- 取消：处理关闭操作（例如，稍后再次提示）
安全注意事项
- 服务器**绝不能**通过信息征求请求敏感信息
- 客户端**应该**实现用户批准控制
- 双方**应该**根据提供的模式验证信息征求的内容
- 客户端**应该**清楚地标明是哪个服务器在请求信息
- 客户端**应该**允许用户随时拒绝信息征求请求
- 客户端**应该**实施速率限制
- 客户端**应该**以清晰的方式呈现信息征求请求，说明正在请求什么信息及其原因
