MCP capability negotiation 怎么确认客户端支持 elicitation：form 与 url 的分支判断

接入 MCP 的服务端最容易在第一次交互时踩坑：客户端声明了 elicitation，并不代表它同时支持 form 和 url。正确做法是先读取初始化阶段的能力，再根据已声明的模式选择请求；遇到敏感信息时还要把交互放到 URL 模式，不能把密钥塞进客户端表单。

把 capability negotiation 当成发送 elicitation 前的门禁：只发客户端明确支持的模式，普通资料走 form，敏感交互走 url；能力缺失或用户拒绝时，原请求必须停在可恢复状态。

先看初始化能力，再决定请求模式

MCP 的 elicitation 是服务端在处理其他请求时向用户补充信息的一种协议交互。客户端需要在初始化阶段声明 capabilities.elicitation，服务端随后才能知道自己能否发送对应模式。

判断顺序可以压缩成一条很短的路径：读取 capabilities，确认存在 elicitation，再分别检查 form 或 url。没有能力声明时，服务端不应猜测客户端会弹出什么界面。

form 与 url 不是同一个输入框的两种外观

form 是带结构约束的站内收集：服务端可以提供 requestedSchema，客户端负责展示字段、校验输入并让用户在提交前复核。它适合姓名、邮箱、筛选条件等一般资料。

url 是站外交互：客户端把目标域名展示给用户，经明确同意后打开页面，敏感数据不会经过 MCP 客户端。服务端仍要提供清楚的 message、有效的 URL 和唯一的 elicitationId，并让用户知道为什么要跳转。

因此，不能把“客户端支持 elicitation”直接写成“客户端支持所有 elicitation 模式”。兼容场景下，空的 elicitation 对象只按支持 form 处理；服务端发送 url 前必须看到明确的 url 能力。

服务端的分支判断怎么落地

可以把一次请求拆成四个检查点。第一，保存初始化响应中的能力快照，并按客户端连接和用户身份关联。第二，普通输入只在存在 form 能力时发送表单请求。第三，遇到密码、API key、access token 或支付凭据时，只选择已声明的 url 模式。第四，两个模式都不支持时返回可解释的失败结果，不要悄悄降级成明文输入。

这条边界也适用于外部 OAuth。URL 模式用于让 MCP 服务端代表用户完成第三方授权，不是用来替代 MCP 客户端与 MCP 服务端之间的授权。两条授权关系要分别记录，不能把客户端凭据透传给第三方。

用户动作要按 accept、decline、cancel 分开处理

elicitation 的结果有三种动作。accept 表示用户明确批准；form 模式通常会带回 content，url 模式的 accept 只表示同意开始站外交互。decline 表示用户明确拒绝，服务端应给出替代路径或结束当前操作。cancel 则更像关闭弹窗、返回上一页或页面加载失败，适合保留原任务并允许之后继续。

尤其不要把 url 模式的 accept 当作“授权已经完成”。官方规范明确把站外流程和 MCP 客户端隔开；服务端需要等待自己的状态变化或完成通知，再决定是否重试原请求。

上线前的安全复查清单

• 服务端是否拒绝了客户端未声明的模式。
• form 是否只收集一般资料，是否屏蔽了敏感凭据。
• url 是否使用 HTTPS、展示完整域名，并要求用户明确同意。
• URL 中是否混入了用户凭据、个人信息或预授权参数。
• 服务端是否把 elicitation 状态绑定到真实用户，而不是只绑定一个容易复用的会话标识。
• 用户拒绝、取消、页面未完成和完成通知缺失时，是否都有可恢复路径。

常见问题

客户端只声明了空的 elicitation 对象，能发送 url 吗？

不能。兼容规则把空对象视为仅支持 form；要发送 url，必须看到明确的 url 能力。

收集邮箱也必须使用 url 吗？

不必。邮箱等一般资料可以使用 form，但仍应让用户知道请求来自哪个服务端，并允许修改或拒绝。

url 模式返回 accept 后就能继续原请求吗？

不能直接假定完成。accept 只代表同意开始站外交互，服务端应根据自身状态或完成通知确认流程结果。

没有 url 能力但业务必须输入 API key 怎么办？

应暂停这次操作并提示客户端升级或改用支持 url 的客户端，不要把 API key 改成 form 字段。

把能力协商变成发布门禁

实际实现中，最稳妥的做法是把能力快照、模式选择、用户动作和站外完成状态写进同一条可追踪记录。每次发送 elicitation 前重新核对模式，每次恢复原请求前核对用户身份和交互状态。这样既能兼容只支持 form 的旧客户端，也能把敏感数据留在正确的安全边界内。