Skip to main content
  • 状态(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 来校验出发日期:
工具期望的输入 JSON schema 只能描述正则表达式语句。而”日期是否在过去”这一实际的程序化检查无法在此处用 JSON schema 表达。即便模型提供了一个语法正确、能通过 JSON schema 校验的日期,也无法保证它在未来。当校验错误被抛出并作为协议错误返回时:
  1. 模型收不到解释为何该日期被拒绝的错误消息
  2. 模型多次重复相同的错误(例如,当用户只指定日和月或相对日期时,Cursor 通常一贯地发送 2024 年的日期,并重复相同的 tools/call 请求 3 次,却得不到任何关于工具调用为何失败的信息)
  3. 任务失败,尽管模型在获得适当反馈时本能够自我纠正
  4. 用户感到沮丧,不得不手动干预

本提案的收益

  1. 更高的任务完成率:模型可以在无人工干预的情况下自我纠正校验错误
  2. 更好的用户体验:减少失败、更快完成任务
  3. 利用模型能力:现代 LLM 擅长理解并响应错误消息
  4. 减少 API 调用:模型在首次出错时即自我纠正,重试次数更少

规范

当前行为

工具错误规范目前提供的指导含糊:
  • “无效参数(Invalid arguments)“应视为协议错误
  • “无效输入数据(Invalid input data)“应视为工具执行错误
这种含糊导致实现不一致,宝贵的错误反馈由此丢失。

提议的变更

以以下变更澄清规范:
  1. 协议错误中移除”无效参数(invalid argument)“类别。
  2. 工具执行错误应用于所有工具参数校验失败(将 invalid argumentinvalid input data 合并到一个新的 input validation errors(输入校验错误)类别下)

规范文本变更

更新错误处理章节,纳入:

实现

变更前(协议错误)

变更后(工具执行错误)

向后兼容性

此变更向后兼容,因为它:
  • 不改变协议结构
  • 只澄清既有的含糊行为
  • 保留所有既有的错误类型和格式
  • 在不破坏既有实现的前提下改进行为
实现了这一澄清后行为的服务器将提供更好的模型自我恢复能力,同时继续与所有既有客户端协同工作。

参考资料