- 状态(Status): Final
- 类型(Type): Standards Track
- 创建(Created): 2025-08-05
- 作者(Author(s)): @fredericbarthelet
- Issue: #1303
摘要
本 SEP 提议将工具输入校验错误视为工具执行错误(Tool Execution Error)而非协议错误(Protocol Error)。此变更将使语言模型能够在其上下文窗口中收到校验错误反馈,从而无需人工干预即可自我纠正并成功完成任务,显著提高任务完成率。动机
语言模型可以从工具输入校验错误消息中学习,并相应地用纠正后的参数重试 tools/call,但前提是它们在其上下文窗口中收到了错误反馈。协议错误在应用层被 MCP 客户端捕获。只有工具执行错误会作为 JSON-RPC 响应转发回模型。在当前规范下,模型看不到这些错误消息,因而无法自我纠正,导致反复失败和糟糕的用户体验。问题陈述
设想一个航班预订工具,它使用以下zod 校验 schema 来校验出发日期:
- 模型收不到解释为何该日期被拒绝的错误消息
- 模型多次重复相同的错误(例如,当用户只指定日和月或相对日期时,Cursor 通常一贯地发送 2024 年的日期,并重复相同的 tools/call 请求 3 次,却得不到任何关于工具调用为何失败的信息)
- 任务失败,尽管模型在获得适当反馈时本能够自我纠正
- 用户感到沮丧,不得不手动干预
本提案的收益
- 更高的任务完成率:模型可以在无人工干预的情况下自我纠正校验错误
- 更好的用户体验:减少失败、更快完成任务
- 利用模型能力:现代 LLM 擅长理解并响应错误消息
- 减少 API 调用:模型在首次出错时即自我纠正,重试次数更少
规范
当前行为
工具错误规范目前提供的指导含糊:- “无效参数(Invalid arguments)“应视为协议错误
- “无效输入数据(Invalid input data)“应视为工具执行错误
提议的变更
以以下变更澄清规范:- 从协议错误中移除”无效参数(invalid argument)“类别。
- 工具执行错误应用于所有工具参数校验失败(将
invalid argument和invalid input data合并到一个新的input validation errors(输入校验错误)类别下)
规范文本变更
更新错误处理章节,纳入:实现
变更前(协议错误)
变更后(工具执行错误)
向后兼容性
此变更向后兼容,因为它:- 不改变协议结构
- 只澄清既有的含糊行为
- 保留所有既有的错误类型和格式
- 在不破坏既有实现的前提下改进行为