协议版本: draft
启发式是在此MCP规范版本中新引入的，其设计可能在未来的协议版本中演进。
Model Context Protocol (MCP) 提供了一种标准化的方式，让服务器在交互过程中通过客户端向用户请求额外信息。这一流程使得客户端能够保持对用户交互和数据共享的控制，同时让服务器能够动态地收集必要信息。 服务器使用 JSON 模式向用户请求结构化数据，以验证响应。

​
用户交互模型

MCP 中的启发功能允许服务器通过用户输入请求来实现交互式工作流，这些请求可以嵌套的在其他 MCP 服务器特性中。 实施者可以根据他们的需求自由通过任何界面模式展示引导——协议本身并不强制规定任何特定的用户交互模型。
对于信任与安全:
  • 服务器不得使用引导来请求敏感信息。
应用程序应当:
  • 提供用户界面，明确显示哪个服务器正在申请信息
  • 允许用户在发送前查看和修改他们的响应
  • 尊重用户隐私并提供清晰的拒绝和取消选项

​
能力

支持获取信息能力的客户端 必须 在 初始化 期间声明 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"]
}

​
支持的Schema类型

模式被限定为以下基本类型：
  1. 字符串模式 
    {
  "type": "string",
  "title": "Display Name",
  "description": "Description text",
  "minLength": 3,
  "maxLength": 50,
  "pattern": "^[A-Za-z]+$",
  "format": "email",
  "default": "[email protected]"
}
    支持的格式：email, uri, date, date-time
  2. 数值模式 
    {
  "type": "number", // 或 "integer"
  "title": "Display Name",
  "description": "Description text",
  "minimum": 0,
  "maximum": 100,
  "default": 50
}
  3. 布尔模式 
    {
  "type": "boolean",
  "title": "显示名称",
  "description": "描述文本",
  "default": false
}
  4. 枚举模式 
    {
  "type": "string",
  "title": "显示名称",
  "description": "描述文本",
  "enum": ["option1", "option2", "option3"],
  "enumNames": ["选项1", "选项2", "选项3"],
  "default": "option1"
}
客户端可以用此架构进行：
  1. 生成相应的输入表单
  2. 发送前验证用户输入
  3. 为用户提供更好的指导
所有基本类型都支持可选默认值，以提供合理的初始点。支持默认值的客户端应使用这些值预先填充表单字段。 请注意，为简化客户端用户体验，有意不支持复杂的嵌套结构、对象数组及其他高级JSON Schema功能。

​
响应操作

启发式响应使用三种动作模式来清晰区分不同的用户行为: 
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "action": "accept", // or "decline" or "cancel"
    "content": {
      "propertyName": "value",
      "anotherProperty": 42
    }
  }
}
三种响应操作是：
  1. 接受 (action: "accept"): 用户明确批准并提交数据
    • content字段包含符合请求模式的提交数据
    • 示例：用户点击了“提交”、“确定”、“确认”等。
  2. 拒绝 (action: "decline"): 用户明确拒绝了请求
    • 通常省略 content 字段
    • 示例：用户点击了"拒绝"、"拒绝"、"否"等选项。
  3. 取消 (action: "cancel"): 用户未做明确选择即取消
    • 通常省略 content 字段
    • 示例：用户关闭了对话框，点击了外部，按下了 Escape 键等。
服务器应当适当处理每个状态：
  • 接受: 处理已提交的数据
  • 拒绝: 处理明确拒绝的情况（例如，提供替代选项）
  • 取消: 处理驳回情况 (例如：稍后再次提示)

​
安全注意事项

  1. 服务器 不得 通过诱探索取敏感信息
  2. 客户端应该实现用户批准控制
  3. 双方 应当 根据提供的模式验证引导内容
  4. 客户端应当明确指示服务器正在请求信息
  5. 客户端应当允许用户随时拒绝请求
  6. 客户端应当实现速率限制
  7. 客户端 应该 以清晰的方式呈现引导请求，表明正在请求什么信息以及原因