MCP elicitation/create 怎么设计：工具调用中的表单输入与敏感信息边界

给 MCP 工具对接配置向导时，最容易把两类场景混在一起：一类是服务器需要用户补充普通业务参数，另一类是服务器需要用户输入密码、API 密钥这类敏感凭据。MCP 的 elicitation/create 解决的是前一类场景的需求：在一次客户端发起的工具调用流程里，由服务器向客户端请求额外的、可校验的用户输入；敏感信息相关的交互必须转到用户明确授权的外部安全页面，不能直接塞进普通表单里处理。

把 MCP elicitation 设计成“补齐非敏感业务参数”的交互逻辑：客户端先声明自身支持的能力，服务器只在原始请求链路内发起 elicitation/create，用户可以自主选择接受、拒绝或者取消；遇到密码、令牌和支付信息类内容时，直接停止使用表单收集模式。

先把交互边界定清：服务器缺什么信息

设想一个 MCP 工具 create_deployment：用户已经选好要操作的仓库，但服务器还缺部署环境和发布分支这两个信息。环境名、分支名、是否开启灰度，都属于可以让用户在客户端界面里查看和修改的普通参数。服务器可以在工具处理过程中发起一次 elicitation，让客户端把这些字段收集回来，之后再继续执行原本的工具调用逻辑。

这个能力不是“服务器随时弹窗”的无限制通道。官方规范要求这类从服务器发往客户端的请求，必须和一个正在处理的客户端请求强关联，例如 tools/call；不能让服务器在无关的新连接上，独立主动发起用户输入请求。这么做既能让客户端清楚当前交互的上下文，也能让取消、超时和审计记录都归属于同一条调用链。

客户端初始化时先声明 form 能力

支持 elicitation 的客户端要在初始化能力配置里，声明它能处理的交互模式。兼容稳定版 2025-06-18 时，用空对象就可以表达表单模式能力：

{
  "capabilities": {
    "elicitation": {}
  }
}

如果客户端实现了更细粒度的能力声明，可以把表单模式的支持范围写得更明确。服务器收到初始化结果后，要把能力协商当作硬性门槛：客户端没有声明 elicitation 相关能力，就不要继续发送 elicitation/create，直接返回缺少参数的提示，或者让调用方重新发起已经带全参数的请求。

用 requestedSchema 约束普通输入，不要直接信任自由文本

表单请求会包含一条面向用户的说明，以及一个做了限制的 JSON Schema。下面的示例只收集部署环境、分支和灰度开关三个字段；字段统一放在顶层，类型和必填关系由客户端侧先做校验：

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "elicitation/create",
  "params": {
    "message": "请补充本次部署的目标环境和发布分支",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "environment": {"type": "string", "enum": ["staging", "production"]},
        "branch": {"type": "string", "minLength": 1},
        "canary": {"type": "boolean"}
      },
      "required": ["environment", "branch"]
    }
  }
}

服务器收到结果后仍然要再次做校验。客户端的表单校验只是优化交互体验，完全不能替代服务端的权限判断、分支白名单校验和生产发布审批流程。尤其是 environment=production 这类字段，不能只校验类型正确就直接授予执行资格。

三种用户动作要分别做流程收口

elicitation 的结果不只有“拿到数据”和“报错”两种场景。用户可能提交了合法内容，也可能明确拒绝提供信息，或者只是直接关闭了当前交互界面。服务器要把这三种状态映射成不同的工具结果处理逻辑：

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "action": "accept",
    "content": {
      "environment": "staging",
      "branch": "release/2026-08",
      "canary": true
    }
  }
}

• accept：重新校验字段合法性和当前用户权限，再继续后续工具逻辑；不要只检查客户端是否返回了合法 JSON 就直接执行。
• decline：用户不愿提供对应信息，返回可读性强的未完成状态，不要自动重试弹出收集窗口。
• cancel：交互被关闭或者流程中止，释放本次调用的临时状态，必要时引导用户从原操作入口重新发起。

如果工具会修改外部资源，最好把“收集参数”和“执行变更”拆成两个明确的阶段：在确认用户 accept 之后，重新计算授权状态和资源状态，确认所有条件都满足，再提交变更。用户停留在表单页面的这段时间，分支权限或者部署窗口规则可能已经发生变化。

敏感输入要切换到 URL 模式处理

普通表单模式完全不适合收集密码、API 密钥、访问令牌和支付凭据。原因不只是“界面上看起来不安全”：表单内容会进入客户端可见的数据流，服务器也很可能在日志、调试信息或者模型上下文中意外泄漏这些敏感值。

当前 MCP 规范草案引入了 URL 模式，用来把敏感交互放到客户端之外的目标页面处理。客户端展示服务器请求的上下文、目标域名，征得用户同意后跳转，服务器通过 elicitationId 关联后续状态；这个模式不是要替代 MCP 客户端授权流程，也不会修改客户端原本携带的 bearer token。如果客户端只支持 form 模式，服务器不能强制把 URL 模式交互塞给它，要明确返回不支持的提示。

URL 模式也不是安全自动化的通行证。客户端仍要拦截钓鱼式跳转，服务器要校验回调状态和用户的绑定关系，跳转的外部页面也必须使用 HTTPS 和短时有效的授权状态。这里提到的“切换模式”指的是调整安全边界，不代表任何外部页面都可以直接跳转打开。

把客户端体验做成可恢复的流程

一个可用的客户端至少要在界面上明确告知用户“当前是哪个服务器正在请求什么内容”，让用户在提交前检查并修改表单内容，同时提供清晰的拒绝和取消入口。针对 URL 模式，还要明确显示目标主机信息，告知用户即将发生外部跳转。

服务端可以按照下面的检查顺序实现对应逻辑：

1. 读取初始化能力配置，确认客户端支持目标交互模式。
2. 根据缺少的业务字段构造最小粒度的 requestedSchema，不要顺便收集和当前操作无关的数据。
3. 在当前 tools/call 链路内发起请求，同时设置调用级别的超时规则。
4. 收到 accept 响应后，重新做类型、权限、资源版本和审批状态的校验。
5. 针对 decline、cancel、超时三类场景分别记录原因，同时保证所有临时状态都可以正常释放。
6. 如果字段涉及凭据或者付款，直接改走 URL 模式或者业务方已有的安全授权流程。

常见问题

elicitation/create 能不能由服务器主动定时弹出？

不应做这类设计。所有请求都要关联到正在处理的客户端请求，比如正在执行的工具调用；在独立连接上由服务器主动发起的交互，不属于这条协议覆盖的流程范围。

requestedSchema 能不能写任意复杂的嵌套 JSON Schema？

稳定版表单能力使用的是受限的 Schema 形态，核心聚焦在顶层属性和基础类型校验。复杂业务对象可以拆成多次最小粒度交互，或者改由客户端先收集完成后直接作为工具参数提交。

用户点击 decline 之后，服务器应该重试吗？

默认不应该自动重试。decline 是用户明确表示不提供对应信息，重复弹出窗口会破坏交互的可控性；可以返回缺少参数的可恢复结果，让用户自主选择是否重新发起操作。

API 密钥可以放进 form 的 password 字段吗？

不建议这么做，也不符合敏感信息边界的设计原则。字段标成 password 只是修改了前端的展示方式，不能改变数据会经过客户端和整条调用链的事实；这类内容应该用 URL 模式或者已有的安全凭据流程来处理。

MCP elicitation 的价值不在于多了一个弹窗能力，而在于把“工具缺少必要信息”变成一套有能力协商、有用户确认、有结果分支处理的协议流程。把普通业务字段留在可审阅的 form 模式，把敏感交互移到明确的 URL 安全边界，再在用户确认 accept 之后重新做权限和资源校验，工具才能真正具备可恢复的交互能力。