Study: MCP error messages are aimed at developers, and more capable agents suffer greater harm

只能调用服务器工具的智能体，会照做 MCP 错误信息里写给开发者的下一步；这一步做不到时，它们常常停手，尽管自己的工具可以完成修复。

• 场景：这类错误信息假定读者能开终端、改配置、打开网页或等待后再调用。作者称许多 MCP 服务器是 Web API 的薄包装。论文引述，116 个官方服务器中 88.6% 全部或部分基于 REST，92% 的工具是直接的 API 包装。服务器对所有调用方返回同一段文本，看不出对方有没有这些手段。
• 为何现在更要紧：带连接器的对话应用，或只允许工具调用的框架，不能执行命令或打开网页。作者引述 OpenAI 与 Anthropic：GPT-6 Astra 与 Claude Fable 5 比前代更重视书面指令，为更早模型写的指引可能把它们约束过紧。
• 现有指引没写的部分：MCP 规范把工具执行错误当作让模型纠正自己并重试的反馈；Anthropic 的指南建议给出具体、可执行的改进。作者称两者都没有说明谁能执行，也没有报告这一步对恢复有多大帮助。
• 论文做什么：作者认为，任何调用方都能执行的步骤，是调用该服务器自己的工具。论文统计 150 个常用服务器里的错误文本，并让只能使用 BFCL 工具的五个模型在同一失败点上比较不同文本；一侧把步骤改写成工具调用，另一侧在模型阅读前删掉步骤。

论文把相关工作分成三条线，并把自己放在「读者能否执行错误信息里的步骤」上。

给程序员和智能体的错误信息

• 开发者向的错误文本：Myers 与 Stylos（2016）研究开发者如何阅读文档和错误输出并行动；HTTP 的 problem details（Nottingham 等，2023）把问题类型与给人读的细节分开；Becker 等（2019）所综述的编译器错误信息，论文称常常被认为没有帮助。
• 细节与修复率：Krishnamurthi 与 Flatt（2026）报告，从类型错误信息里去掉细节会降低编程智能体的修复率。
• 工具反馈：论文称工具反馈帮助模型修改输出（Gou 等，2024；Huang 等，2024）。Su 等（2026）指出工具调用模型常重复失败调用，并用结构化反思训练诊断失败、提高恢复。作者称自己看的是另一种性质：读者能否执行消息里的步骤。

智能体会执行工具输出里的指令

• 攻击者写入的指令：AgentDojo（Debenedetti 等，2024）与 InjecAgent（Zhan 等，2024）研究智能体执行攻击者放在工具输出中的指令。
• 能力与遵从：Liu 等（2026）报告，能力最强的模型最稳定地遵从植入 MCP 工具描述的指令。Su 等（2026，DistractionIF）报告，更大的模型更容易被良性、类似指令的句子带走。
• 错误的工具输出：ToolRobustBench（Zheng 等，2026）与 ToolMisuseBench（Sigdel 与 Baral，2026）研究智能体过度信任错误的工具输出。论文称，本文的步骤由工具作者善意撰写，并且对开发者是正确的。

MCP 生态与写作规范

• 服务器研究：Taraghi 等（2026）整理 MCP 软件中的真实故障；Hasan 等（2026）讨论工具描述的缺陷；Mastouri 等（2025）研究把 REST API 包装成 MCP。
• 规范与指南：MCP 规范（2025-11-25）把工具执行错误描述为供模型自我纠正并重试的反馈；Anthropic（2025）建议错误响应写出具体、可执行的改进。作者称两者都没说明谁能执行，也没报告该步骤对恢复的帮助。
• 新模型与书面指令：作者引述 OpenAI（2026）与 Anthropic（2026）：GPT-6 Astra 与 Claude Fable 5 更重视书面指令，为更早模型写的指引可能过度约束它们。

作者称尚未见到研究 MCP 服务器所返回错误文本、以及智能体如何处理这些文本的工作。实验比较的是 BFCL V4 多轮任务里、同一场景的不同错误文本。

作者分两步做。先在已部署服务器的源码里统计错误文本是否给出下一步、以及该步骤是否依赖服务器看不见的调用方条件。再在 BFCL V4 多轮任务上固定失败点，只更换返回给模型的文本。补救也分两侧：MCP 开发者把步骤写成对该服务器某个工具的调用；不能改第三方服务器的智能体开发者，在模型阅读前删掉步骤。

调查已部署服务器

• 样本：取 GitHub 上星标最高、有公开源码、用官方 MCP SDK 注册工具、且过去一年有更新的 150 个服务器。星标从 426 到 186,635，中位数 1,609。每个服务器最多抽取 30 处失败时返回给模型的文本，共 3,001 条。Section 7 写明调查对应 2026 年 9 月的这类服务器。
• 标签：记录是否告诉调用方下一步；若有，该步骤是否只在服务器观察不到的条件下才成立，例如调用方的工具、登录或权限。标签由 OpenAI Codex 智能体按随数据发布的 codebook 从源码判定。
• 后文实验选取的步骤：凭证错误里的终端命令，以及速率限制里不点名调用、只让对方等待后再试的说法。作者称，有 12 例来自 5 个服务器，服务器自己已经提供能完成修复的工具，实验再现的是这一情形。

场景与七类失败

• 构造：从 BFCL V4 多轮任务重放参考调用，直到选定的一次调用，把该调用换成失败调用并保存环境状态。工具有可执行实现，回合有基于状态的成功检查。共 168 个场景，七类各 24 个。
• 七类：错误的单位或格式、缺少必填字段、调用了错误工具、过期凭证、缺失资源、会话缺少权限、达到速率限制。Table 2 列出每类如何失败、环境接受何种修复、以及用哪一部分状态判定恢复。
• 环境接受的修复：过期凭证和缺少权限，都是用对话中早先的凭证登录后再发原调用。速率限制是立刻再发同一次调用，不强制等待，服务状态在拒绝时未改变。缺失资源时，调用中的标识对任务点名的资源不存在，智能体能在自己的调用里看到该标识。

六种错误文本

• 四类条件：每个场景六条文本（Table 3）。通用通知在所有场景中相同，只说操作失败。原因陈述只用工具在调用失败时已经知道的信息。正确下一步点名一个能从保存状态消除失败的动作，有两种说法。错误下一步也有两种。
• 两种错误步骤：可执行形式点名智能体拥有的工具，但用在错误目标上，使动作失败或离开任务目标。不可用形式要求智能体没有的东西，例如终端命令、环境变量或工具列表之外的工具。说法复用调查里的真实建议。
• 原始步骤与改写：六条中有两条复现调查里的步骤，另两条把同一种修复写成对该服务器某个工具的调用。过期凭证上，原始步骤是不可用的终端命令，改写步骤是第二种正确说法，点名该服务的登录工具。速率限制上，原始步骤是第一种正确说法，只要求等待后再试；改写步骤点名刚才失败的那次调用。

模型、流程与恢复

• 模型与次数：五个 OpenAI 模型，论文列表顺序为 GPT-5.5、GPT-5.6 Sol、GPT-6 Sol、GPT-6 Astra（最大的 GPT-6）、GPT-6 Luna（最小）。推理力度 high，默认采样，访问日为 2026 年 9 月 24、25 与 27 日。每个场景、文本与模型 3 次，共 15,120 次。
• 动作与停止：从保存状态开始，把文本作为失败调用的结果交还，再让智能体继续，直到它结束回合或已做 8 次工具调用。动作空间只是该任务的 BFCL 工具，没有终端、时钟或浏览器。
• 判定与区间：恢复指该回合通过 BFCL 状态检查：结束时每个服务的状态等于本回合参考调用之后的状态。同时记录调用次数、token、是否调用了错误步骤点名的工具、是否让用户执行该步骤、是否未修复就结束。分析单位是场景。95% 区间来自失败类型内对场景的 10,000 次 bootstrap，同一模型的各文本共用同一组重抽样。五模型合计值是五个模型数值的平均。

阅读前删掉步骤

• 输入与输出：对每个过期凭证场景中带下一步的四条文本（两种正确说法和两种错误步骤，共 96 条）使用一段提示词。它要求删去告诉调用方下一步做什么的句子，保留说明出了什么问题的句子，其余原文不改、不另加内容。Section 4.3 给出了完整提示词。
• 谁执行：过滤由 GPT-6 Luna 完成。五个模型再在同一设定下对每条过滤后的文本各继续 3 次，另有 1,440 次试次。

在只能调用 BFCL 工具的设定下，换掉失败调用返回的文本会改变恢复；作者报告损失在过期凭证的终端命令上随所列较大模型增加，GPT-6 Astra 最高。

实验设置

• 模型：GPT-5.5、GPT-5.6 Sol、GPT-6 Sol、GPT-6 Astra、GPT-6 Luna。推理力度 high，默认采样，访问日为 2026-09-24、25、27。Section 7 写明模型名是 API 别名。Claude Fable 5 只出现在作者引述中，不在这五者之列。
• 场景：BFCL V4 多轮任务，168 个场景，七类失败各 24 个（Section 4.1、Table 2）。
• 比较的文本：通用通知、仅原因、正确步骤的两种说法、可执行的错误步骤、不可用的错误步骤（Table 3）。没有与已发表恢复方法做外部基线对比。
• 指标：恢复率是回合通过 BFCL 状态检查的比例。同时报告每试次工具调用数、token，以及未修复就结束的比例。
• 样本量与停止：每组场景×文本×模型 3 次，主实验 15,120 次。最多 8 次工具调用；动作空间只有该任务的 BFCL 工具。
• 区间：95% 区间为失败类型内 10,000 次场景 bootstrap（Section 4.4）。论文未报告错误文本标注的一致性，也未报告另做人工判定恢复。

主结果

过期凭证、24 个场景×3 次的恢复率如下（据 Table 4）。「删掉该命令」是 GPT-6 Luna 用提示词去掉终端命令之后。区间见原表。

Swipe horizontally to read the table

模型	终端命令	仅原因	点名登录工具	删掉该命令
GPT-5.5	58%	76%	85%	86%
GPT-5.6 Sol	57%	92%	89%	89%
GPT-6 Sol	46%	85%	82%	76%
GPT-6 Astra	6%	75%	75%	75%
GPT-6 Luna	57%	83%	88%	85%
五模型均值	45%	82%	84%	82%

• 作者给出的降幅：相对仅原因，终端命令的损失在 Section 5.1 写为 GPT-5.5 的 18 个、GPT-5.6 Sol 的 35 个、GPT-6 Sol 的 39 个、GPT-6 Astra 的 69 个百分点，小模型 GPT-6 Luna 为 26 个。Astra 比 GPT-5.5 多 51 个（区间 29 到 72）。作者称损失随模型增大，并把 Luna 单独写出。五个模型上，终端命令都低于仅原因。
• Astra 如何结束：该条件下 Astra 每试次 0.60 次工具调用。未修复的 68 次中有 48 次，最后消息把修复留给用户，例如请用户重连或登录，或指向该命令。作者称登录工具已在其工具列表中。作者把这种现象叫做 literal compliance：执行不了建议步骤时，放弃自己的工具可以完成的修复，并认为这与 OpenAI 对 Astra 更重视书面指令、更早交还工作的描述一致（Section 6）。
• 改写与删除：作者称点名登录工具后的恢复与仅原因大致相同。五模型均值的调用和 token 更少，为 2.89 次、13,643 token，仅原因为 3.25 次、14,860 token；GPT-5.5 的这两项高于仅原因（Table 4）。恢复路径是登录后再重复原调用。删掉终端命令后的均值与仅原因相同，但不是每个模型都相同。

150 个服务器里的下一步

• 规模：3,001 条中 949 条给出下一步，其中 477 条依赖调用方（Table 1）。作者称几乎每条都写了失败原因。
• 三类外部失败：凭证、权限与速率限制共 209 条消息、128 条下一步，99 条依赖调用方。其中 93 条要求只限 MCP 工具的智能体做不到的事：改配置 55、网页操作 24、终端命令 13、等待 1。
• 实验对应的子集：凭证错误 67 条下一步中 62 条要求改配置、网页或终端命令；12 例来自 5 个服务器，服务器自己有能修复的工具。速率限制 30 条中 20 条说等待后再试，没有一条点名要重复的调用（Section 3）。

速率限制

• 条件：24 个场景。原始步骤只说等待后再试，不点名调用；改写步骤点名失败调用。环境不强制等待，同一次调用会立即成功（Table 2、Section 4.2）。
• 结果：只说等待时，按 Table 5 的模型顺序，恢复率为 4%、7%、8%、11%、1%，均值 6%（区间 1 到 13）；未修复即结束的比例在 89% 到 99%，均值 0.37 次调用、3,098 token。点名调用后各模型在 78% 到 99%，均值 88%（区间 83 到 93）。作者称提高 82 个（区间 75 到 88），均值变为 1.42 次调用、5,409 token，大约多一次调用。
• 与凭证场景的次序不同：此条件下恢复率最低的是 GPT-6 Luna，最高的是 GPT-6 Astra。作者没有把「最新模型最常停止」写到这一条件上。

提示词删除与七类失败

• 过滤是否等于仅原因：GPT-6 Luna 把 96 条带下一步的过期凭证文本全部收成与原因陈述相同的文本。在终端命令文本上，恢复率平均提高 37.5 个（区间 26.9 到 47.8），均值与仅原因相同（Section 5.3、Table 4）。被删步骤原本正确时，恢复率变化为 −1.7 到 −0.8 个，区间都含 0。
• 同一提示词用于调查文本：764 条能把步骤与原因分开的消息中，752 条去掉了步骤，548 条其余部分逐字保留。对全部 949 条带步骤的消息运行，花费 0.09 美元。作者称删除适合凭证错误，因为原因已经指向修复；在缺少权限或速率限制上，仅原因留下的任务大多未恢复，删掉正确步骤会把修复一起去掉（Section 6）。
• 文本只在失败不在调用里时拉开差距：下面是五模型平均恢复率（%，Table 6）。正确步骤的两句随类型变化：过期凭证与缺少权限上，作者把 53% 或凭证场景的改写对应到点名登录工具，把 28% 对应到只说重新授权；速率限制上，步骤 1 是只说等待，步骤 2 点名调用。另外四类的两句原文，论文没有逐类写出。

Swipe horizontally to read the table

失败类型	通用通知	仅原因	正确步骤1	正确步骤2	不可用步骤
错误单位或格式	83%	79%	82%	82%	81%
缺少必填字段	86%	88%	88%	88%	86%
调用了错误工具	80%	81%	82%	81%	81%
过期凭证	61%	82%	84%	84%	45%
缺失资源	98%	98%	97%	97%	98%
缺少权限	0%	0%	28%	53%	0%
达到速率限制	59%	5%	6%	88%	8%

作者称，错误单位或格式、缺少字段、错误工具、缺失资源上，每种文本与通用通知相差都不超过 4 个；畸形调用本身让智能体知道要改什么。仅原因时，缺少权限为 0%，速率限制为 5%；作者称这两类上至少 89% 的试次未修复就结束，并认为这符合 HTTP 对 403 与 429 的客户端读法。可执行的错误步骤（Table 6，未列入上表）在速率限制上为 66%，过期凭证 81%，缺少权限 0%，其余四类为 81%、87%、81%、99%。作者称，速率限制上即使步骤点名了错误工具，智能体仍会重复失败的调用。

其他消融与分析

• 过期凭证上，终端命令下未修复即结束的五模型均值为 55%，仅原因 18%，点名登录工具 16%，删掉该命令 17%（Table 4）。
• Astra 在终端命令下的恢复率区间为 0% 到 13%，五模型均值区间为 35% 到 54%（Table 4）。
• 作者称，在服务器工具能够修复的三类失败上，把步骤写成工具调用得到更高恢复率（Table 4、5、6）；凭证场景里这是相对终端命令而言，均值 84% 对 45%。
• 速率限制的改写步骤下，未修复即结束的均值为 12%，各模型工具调用为 1.19 到 1.83 次（Table 5）。
• 引言称能力越强越常停止；Table 4 的终端命令列里，Luna 与 GPT-5.5、GPT-5.6 Sol 同为 57% 左右，更低的是 GPT-6 Sol 与 Astra。
• 作者引述 Liu 等（2026）与 DistractionIF（Su 等，2026）报告了同一方向，这不是本文的实验（Section 6）。

作者指出的局限与后续方向

作者没有写 Future Work。Section 7（Threats to Validity）写下的范围是：

• 判定范围：恢复按失败所发生的那一回合的 BFCL 状态检查来判定（Section 7）。
• 场景范围：场景覆盖 BFCL 多轮领域中的七类失败（Section 7）。
• 调查范围：调查描述的是 2026 年 9 月 GitHub 上广泛使用的开源 MCP 服务器（Section 7）。
• 模型命名：模型名是 API 别名，并报告了访问日期（Section 7）。

实验覆盖范围

• 被测模型与采样：GPT-5.5、GPT-5.6 Sol、GPT-6 Sol、GPT-6 Astra、GPT-6 Luna 共 5 个；推理力度 high，默认采样；每个场景、文本与模型 3 次，主实验 15,120 次（Section 4.3）。
• 任务与动作：BFCL V4 多轮任务 168 个场景，七类各 24 个。动作空间是该任务的 BFCL 工具，无终端、时钟或浏览器，每试次最多 8 次工具调用（Section 4.1、4.3）。
• 文本与过滤：每场景六条文本。过滤只用于过期凭证场景中带下一步的 96 条，由 GPT-6 Luna 执行，五个模型再各继续 3 次，共 1,440 次（Section 4.2、4.3）。
• 调查标注：150 个服务器、每服务器最多 30 条、共 3,001 条，由 OpenAI Codex 按 codebook 标注（Section 3）。论文未报告 Codex 的数量，也未报告标注一致性。
• 判定与区间：恢复即 BFCL 状态检查。95% 区间来自 10,000 次场景 bootstrap，五模型合计值是各模型数值的平均（Section 4.4）。论文未报告另行的人工评审。

MCP 错误信息里的下一步常常按人类开发者来写，而只能调用服务器工具的智能体会照着做；做不到就结束回合。作者先统计这类文本，再在 BFCL V4 上只更换错误文本，看回合状态能否回到参考调用之后。

• 文本有多常见：150 个常用服务器的 3,001 条错误信息中，949 条给出下一步，477 条依赖服务器看不见的调用方条件（Table 1）。凭证错误的 67 条下一步里，62 条要求改配置、打开网页或执行终端命令。速率限制的 30 条里，20 条只说等待后再试，没有一条点名要重复的调用。
• 过期凭证：终端命令下，五模型平均恢复率 45%，GPT-6 Astra 为 6%、未修复即结束 94%；相对仅原因，损失从 GPT-5.5 的 18 个到 Astra 的 69 个，最小的 GPT-6 Luna 为 26 个（Table 4、Section 5.1）。点名登录工具后平均 84%。GPT-6 Luna 用一段提示词删掉该命令后平均 82%，与仅原因相同。
• 速率限制与权限：只说等待的平均恢复率 6%，点名要重复的调用后为 88%（Table 5）。缺少权限时仅原因为 0%，只说重新授权为 28%，点名登录工具为 53%（Table 6）。调用本身写错的四类上，作者称各文本与通用通知相差不超过 4 个。
• 作者的结论：作者称之为 literal compliance，并认为这与 OpenAI、Anthropic 对新模型更重视书面指令的描述一致，因此同一段服务器文本在更新的模型上可能失去更多恢复。作者称，MCP 一侧可以把步骤写成服务器工具调用；智能体一侧在凭证错误上可以于阅读前删掉步骤。在缺少权限或速率限制上，只留原因、删掉正确步骤，会把修复一起去掉。作者称场景、错误文本、调查数据、模型输出和代码已经公开。