MCP Elicitation 是什么？工具需要补充信息时，怎样向用户发起询问？

知识点详解：一次补问要经过哪些参与者？

模型追问和协议补问有什么不同？

假设用户让助手安排明天下午的会议，但账号没有默认时区。

模型当然可以在聊天里问“你在哪个时区”。这是对话层的补问，应用随后决定如何把答案交给任务。

Elicitation 则提供一种服务端到客户端的信息请求。执行能力发现缺少输入后，可以通过协议请求客户端呈现，让结果回到相应调用流程。

这并不规定所有缺参数的工具都必须使用 Elicitation。如果应用本来有稳定的表单或对话澄清流程，也可以继续使用。

使用之前，先确认客户端会不会处理

服务端不能默认每个 MCP 客户端都能打开相同表单。

双方需要根据所用版本声明支持的能力和模式。当前客户端不支持时，服务端应返回明确的缺少信息或不支持状态，让应用选择其他流程。

不能一边输出不被理解的请求，一边期待模型自动把它转换成用户界面。

MCP 2025-11-25 的 Elicitation 规范定义了能力、模式和回应。下面的解释限定在这个版本，实际接入还要核对所用客户端与 SDK。

Form 模式怎样补齐一个普通字段？

在会议场景中，服务端请求时区信息，说明用途，给出该版本支持的结构化字段要求。

客户端把请求呈现给用户。用户完成输入后，返回接受及相应内容；用户拒绝或关闭交互，则返回对应的动作。

服务端收到以后，先检查字段，再回到原始任务。它不能拿另一个任务里的回答，替本次会议补参数。

用户回应	任务需要怎样处理
接受并提供内容	检查输入，再决定是否继续
拒绝	不把缺失字段猜成用户已经提供
取消	停止当前交互，按应用规则结束或等待
超时或连接失败	保留明确的未完成状态

表单内容正确，也不说明后续操作已经获得全部授权。

URL 模式为什么要单独讨论？

某些信息需要在外部服务的界面里填写，或者需要完成账号连接。此时不宜把敏感内容直接发送给 MCP 客户端的普通表单。

URL 模式让用户进入相应外部流程，并按协议约定通知或继续处理。应用需要解释用户将前往哪里，校验地址与流程关联，而不是盲目打开服务端随便返回的链接。

它也不等于“任何 URL 都安全”。外部页面的身份、目标和授权范围都需要用户与应用能识别。

更不能把“外部流程已经完成”直接当成任意工具可用。实际取得了什么权限，应回到认证与业务系统检查。

回来以后，怎样继续原来的任务？

服务端应把补充结果对应到原始请求，检查任务是否仍有效。

假设用户填时区期间，会议任务被取消。此时收到结果，不应重新发送邀请。又或者参会人已经变化，就需要重新核对原先确认的范围。

因此，任务标识、当前状态和操作确认需要在应用中维护。Elicitation 提供交互能力，不替你完成整套持久化与恢复设计。

面试官继续追问

Elicitation 是人工审批吗？

它可以参与确认交互，但不能笼统等同于审批系统。补充信息、确认动作和业务审批各有语义，后端需要明确本次回应批准了什么。

客户端不支持，是否只能失败？

可以回到应用提供的澄清、表单或人工流程，但要显式设计。不能把未完成交互当成已经得到用户同意。

用户接受以后，输入还需要校验吗？

需要。字段结构、值域、对象身份与业务约束都要检查。用户点击接受，只说明提交了这次回应。

面试速记卡

• Elicitation：服务端请求，客户端呈现，用户补充信息。
• 前提：核对协议版本、支持能力和交互模式。
• Form：普通结构化输入，不随意收集敏感凭据。
• URL：外部流程要检查目标、身份和任务关联。
• 执行边界：补信息不自动批准后续操作，也不代替权限检查。