MCP Elicitation 怎么补齐工具参数：用户拒绝与结构化响应处理

接入 MCP 工具时，参数不完整并不一定要让调用方直接抛错终止流程。Elicitation 允许服务端把缺失的输入项提交给客户端，引导用户补充完整后再继续后续调用；但真正稳定可用的实现，核心从来不是做个弹窗让用户填表单，而是要把用户接受、拒绝、取消这三类动作都当成独立的明确业务状态来处理。

MCP Elicitation 解决的不是“自动猜参数”

最常见的场景就是某工具需要查询指定项目的日期范围数据，但调用侧只传入了项目名，没给起止时间。以前的常规处理方案一般是两种：要么让大模型自己猜一个默认范围，要么服务端直接返回参数错误。前一种很容易得到和预期不符的错误查询结果，后一种会把本来可以继续推进的交互直接判为失败。

MCP 规范里的 Elicitation 机制，直接把这一步定义成有客户端参与的协同请求。服务端只需要说明自己需要什么信息，要不要展示给用户、怎么展示全由客户端决定；用户拿到提示后可以选择提交补全的信息，也可以直接拒绝或者取消操作。这里的权责边界非常清晰：服务端只能提出补参申请，绝对不能绕过客户端直接替用户确认信息。

先把三种结果当成状态机

动手写代码之前先把各类用户动作对应的处理分支理清楚，后续的实现逻辑会简单很多。

用结构化请求补齐日期范围

以「查询项目周报」这个需求为例，服务端可以发起一个包含项目名、开始日期、结束日期的结构化补参请求。参考的 JSON 示例如下，里面的字段名要和后续工具实际要求的参数名保持完全一致，不要在交互层额外做一次字段含义映射徒增出错概率。

{
  "method": "elicitation/create",
  "params": {
    "message": "请补充周报查询的日期范围",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "project": {"type": "string", "minLength": 1},
        "from": {"type": "string", "format": "date"},
        "to": {"type": "string", "format": "date"}
      },
      "required": ["project", "from", "to"]
    }
  }
}

收到客户端的接受结果后，仍然要在服务器侧校验。至少检查日期能否解析、from 是否早于或等于 to、范围是否超过业务允许的 31 天，并对 project 做权限检查。协议层的结构化约束解决的是形状问题，不等于业务授权已经完成。

客户端能力检查与旧式参数报错怎么取舍

Elicitation 是客户端和服务端之间的协同能力，不能默认所有接入的客户端都支持展示同类型的交互界面。连接建立之后要先读取对方声明的能力清单；如果客户端不支持对应的补参交互，工具直接返回标注了缺失字段名的普通参数错误，告诉调用方需要补全哪些参数就行，不用卡在那里等永远不会到来的用户响应。

这也是这套机制和「服务端自动填默认值」的核心区别：默认值只适合无风险、结果可解释的查询场景；一旦操作涉及项目数据、用户账户、权限校验或者费用相关逻辑，最好还是让用户手动确认参数再执行。如果是批处理或者无人值守的自动任务，更适合在任务启动入口就一次性收齐所有必要参数，不要在任务执行中途弹交互分支卡住流程。

上线前最容易漏掉的四个边界

• 返回值为空：即使用户点了确认接受，返回内容也可能缺字段，直接按校验失败处理，不要直接读取空对象里的默认属性。
• 日期交叉：先把拿到的字符串转成标准日期格式再做范围比较，不能直接对比没有经过规范化处理的原始字符串。
• 重复补参：每一次补参请求都要绑定唯一的上下文标识，用户拒绝之后不要自动重发请求；需要重试的话必须由新的用户主动意图触发。
• 敏感输入：密码、长期有效令牌和完整支付信息这类敏感内容，不适合通过普通交互请求收集，客户端也需要同步向用户说明这些数据的具体用途。

相关问答

MCP Elicitation 能不能替模型自动决定用户选项？

不能。服务端可以描述自己需要的字段和对应的约束规则，但是要不要向用户展示补参界面、要不要接受用户输入、怎么向用户呈现提示内容，这些控制权都在客户端手里。

用户拒绝后应该重发 Elicitation 请求吗？

默认不要自动重发。先返回缺少必要参数或者用户主动拒绝的结果就好；只有收到新的明确用户意图，或者用户自己主动修改了输入参数之后，才适合发起新的补参请求。

结构化响应校验通过后还要做业务校验吗？

必须做。结构化校验只是用来确认返回内容的字段格式是否符合预期，日期范围合理性、资源访问权限、租户数据边界和敏感数据过滤这类校验逻辑，仍然要放在服务端的业务校验层完成。

把补参做成可回收的交互边界

MCP Elicitation 最适合解决「只差一点补充信息，就能让用户简单填完继续往下走」的场景。落地的时候把请求上下文、用户动作、服务端校验验收这三块的记录分开维护，accept 分支走完整的字段校验，decline 和 cancel 分支有明确的流程收口，碰到不支持该能力的客户端直接回退到普通参数错误逻辑。这样新增交互补参能力之后，原来的工具调用流程也不会变成不可预期的隐式黑盒流程。