MCP 工具描述有"坏味道"!通过增强型 MCP 工具描述提升 AI 智能体效率 Model Context Protocol (MCP) Tool Descriptions Are Smelly! Towards Improving AI Agent Efficiency with Augmented MCP Tool Descriptions
首份系统性实证研究：97.1% 的 MCP 工具描述存在"坏味道"，增强全部组件可使任务成功率提升 5.85 个百分点但执行步骤激增 67.46%。
前置知识
Model Context Protocol (MCP)
MCP 是由 Anthropic 提出的开放标准协议，采用 JSON-RPC 客户端-服务器架构，使基于基础模型（FM）的智能体能够通过反射机制发现并调用外部工具（Tool）。每个 MCP 服务器向客户端暴露工具的三大自然语言元数据：工具名（name）、工具描述（description）、输入 schema。MCP 类似于 AI 应用的"USB-C 接口"，Python 与 JavaScript SDK 周下载量已超过 2000 万次。
本文研究的核心对象正是 MCP 协议中流通的工具描述。如果不理解 MCP 的客户端-服务器架构与反射发现流程，就无法理解为什么一段文本（描述）会成为决定智能体成败的关键节点。
工具描述的"双重角色"
作者提出 MCP 工具描述兼具两种性质：(i) 需求规约（requirement-like specification）——定义工具的功能边界、参数约束；(ii) Prompt 式指令（prompt-like instruction）——塑造模型对上下文的推理与决策。这种混合角色使工具描述成为一种新型设计面，其文本缺陷会以规约错误与 Prompt 误导两种形式同时传导。
这一概念框架是全论文的立论基础：将传统软件工程"代码坏味道"概念扩展到自然语言规约层面，并据此定义出 6 类具体的"坏味道"。
代码坏味道（Code Smell）
由 Fowler 和 Beck 提出的经典概念，指代码或软件制品中可能减缓开发、增加未来错误风险但未必立即表现为 bug 的次优结构模式，如"长方法"、"重复代码"、"模糊接口"等。后续研究将其扩展到架构坏味道、测试坏味道、需求坏味道乃至 Prompt 坏味道。
本文将代码坏味道的"识别-打分-重构"研究范式迁移到 MCP 工具描述，构造六维评分量表（rubric），并定义分数 < 3 即为"坏味道"的判定规则。
ReAct 智能体与工具调用循环
ReAct（Reasoning + Acting）是一种让 LLM 在"思考-行动-观察"循环中调用外部工具的范式。智能体先通过 MCP 客户端列出可用工具及其描述，注入到 LLM 上下文；LLM 选择工具并填参；客户端执行；响应回传 LLM 综合最终答案。一个完整任务通常需要多轮工具调用（execution steps）。
本文所有性能指标（SR/AE/AS）都基于 ReAct 智能体在 MCP-Universe 基准上的运行结果，理解"步骤数"为何会随描述变长而膨胀（67.46%）需要该循环的工作机制。
LLM-as-Jury 与多模型一致性评估
用多个异构 LLM（本文用 gpt-4.1-mini、claude-haiku-3.5、qwen3-30b-a3b）对同一对象独立打分，通过组内相关系数 ICC(2,1) 衡量评分者间一致性，并配合人类抽样标注计算 Weighted Cohen's Kappa 验证。
用 LLM 评估 LLM 消费的工具描述本身容易引入评估偏差，本文用 ICC 0.62–0.90 与 Kappa 0.72–0.89 论证了"评分器"的可靠性，这是后续所有量化结论可被采信的前提。
研究动机
MCP 协议要求基础模型仅通过工具的自然语言描述（以及 JSON schema）来推理应选择哪个工具、如何填参，但实证数据表明当前 MCP 生态系统的描述质量极差。作者团队在 103 个 MCP 服务器、856 个工具上扫描后发现，97.1% 的工具描述至少含一种"坏味道"，89.8% 未声明工具局限性（Unstated Limitations），89.3% 缺失使用指南（Missing Usage Guidelines），84.3% 参数含义不清（Opaque Parameters），即使表现最好的 Purpose 维度也有 56% 的工具描述无法清晰表述其功能。官方维护（如 GitHub、Anthropic、PayPal）与社区维护的工具在所有六个维度上的中位数评分均无统计学差异（Bonferroni 校正后 p=1.00），说明问题具有系统性而非局部现象。一个具体的现实场景：Yahoo Finance 的 get_historical_stock_prices 工具描述只说"使用 period 参数或使用 start 和 end"，但未把 start/end 列为正式参数名，也未给出日期格式，导致模型在面对"去年三月发生了什么"这类窄时间窗问题时退化为拉取多年期数据，造成响应膨胀、延迟升高与 token 成本失控。
本文的目标是本文的核心目标有三个：(1) 为 MCP 工具描述建立首个结构化质量评分量表，把"描述好/坏"从主观判断转化为可重复的六维 5 点 Likert 打分，并将分数 < 3 自动映射为具体的坏味道名称；(2) 构建全流程工具链——基于 LLM-as-Jury 的自动坏味道扫描器、半自动描述增强器（augmentor）、可在运行时切换描述的工具描述路由器（Tool Description Router），让 MCP 使用方在不修改服务器代码的前提下实验不同描述；(3) 系统量化"增强所有组件"与"按组件剪枝"对智能体任务成功率（SR）、评估器通过率（AE）、执行步数（AS）三项指标的真实影响，识别其中的成本-性能权衡（accuracy-cost trade-off）。
与已有工作不同的是，已有 MCP 相关研究（如 Ehtesham et al. 的 MCP 服务器代码坏味道研究）只关注代码层缺陷，对工具描述这一同样决定智能体成败的关键工件从未做过系统实证。Prompt 工程方向虽然有 DSPy、MIPROv2、GEPA 等优化框架，但它们优化的是 system prompt 而非 MCP 工具描述这种"规约+指令"混合体。同时，现有的 MCP 智能体评估基准（MCP-Universe、LiveMCPBench、MCPToolBench++）全部采用静态工具描述，假设描述质量不会影响结果，从而在基准设计上回避了真正的可调旋钮。本文的独特切入角度在于：(a) 借鉴软件工程"坏味道"研究范式把工具描述当作一类一阶工程制品对待；(b) 设计"执行轨迹接地（execution-trace grounding）"的增强流程，避免 LLM 在补全 Limitations 与 Examples 时凭空捏造；(c) 用 Pareto 前沿而非单一指标展示不同 (模型, 域) 组合的取舍空间，揭示"小模型+好描述"可以匹敌"大模型+差描述"。
核心方法
方法整体可概括为"评分量表 → 扫描识别 → 接地增强 → 运行时替换 → 基准评估 → 组件消融"六步流水线。先通过开放编码从 15 份社区指南与 Anthropic 官方文档中提炼出 6 个组件（Purpose/Guidelines/Limitations/Parameter Explanation/Length & Completeness/Examples），对每个组件给出 5 级 Likert 描述性锚点；再让三个异构 LLM 对 856 份工具描述独立打分，用 ICC 与人类抽样验证一致性后，把"任一组件均分 < 3"定义为存在坏味道；接着利用 GPT-4.1-mini 配合真实工具执行轨迹（通过 Claude Desktop + MCP 服务器抓取）增强原描述；最后将增强描述通过自研 Tool Description Router 注入 MCP-Universe 基准的 ReAct 智能体，跑出 4 个模型 × 6 个域的性能对比，再做组件级消融找出"小而精"的描述组合。
核心创新是把工具描述从"作者写什么就用什么"的静态文档，转变为可被自动评分、接地增强、运行时替换的工程化制品。具体技术差异点包括：(1) 与传统代码坏味道检测不同，本文的坏味道判定不依赖静态启发式或指标阈值，而是通过多模型 LLM-as-Jury + 5 分制量表 + 分数均值 < 3 的条件生成（公式 $\text{Smell Detected} \Leftrightarrow \frac{1}{N}\sum_{i=1}^{N}\text{Score}_i < 3$），从而把主观质量评估转化为可统计检验的信号；(2) 与 DSPy/GEPA 等 Prompt 优化器不同，本文提出"双阶段接地"——先用源码与输入 schema 增强 Purpose/Guidelines/Parameter Explanation，再用真实执行轨迹（成功 + 失败 + 边界用例）来生成 Examples 与 Limitations 的事实性陈述（Table 14 显示这种接地能把 Parameter Explanation 的忠实度中位数从 0.71 提升到 1.00）；(3) 与 MCP-Universe 自带的 MCP 客户端不同，本文扩展出的 Tool Description Router 支持 `--components` 参数指定子集（如 `P+G` 或 `P+G+L+PEx`），从而在不改服务器代码、不改基准任务的前提下做组件级消融。
方法步骤详情
流水线共五步，每步的输入输出与具体操作如下：(1) 量表开发（§4.1）——输入：15 份社区/官方文档；操作：两位作者独立开放在编码（multi-label 标注，Jaccard 一致性 0.92），合成 6 组件与各自的 5 级评分锚点；输出：6 维 Likert 量表，Score 3 为最小可行阈值，Score < 3 触发对应坏味道（如 Unclear Purpose、Missing Usage Guidelines、Unstated Limitation、Opaque Parameters、Underspecified or Incomplete、Exemplar Issues）；(2) 工具描述采集（§4.2）——输入：基于 Google Scholar 关键词搜索筛选出的 4 篇评估研究；操作：用自研 MCP 客户端通过 `tools/list` 反射请求抓取工具元数据，按官方/社区分组；输出：103 个服务器、856 个工具的描述与 schema 语料；(3) 坏味道扫描（§4.3）——输入：856 份描述；操作：gpt-4.1-mini/claude-haiku-3.5/qwen3-30b-a3b 三个异构 LLM 独立按量表打分，取均值后阈值化；输出：每工具 6 维评分 + 6 种坏味道的布尔标签；(4) 描述增强（§4.4）——输入：原始描述 + 输入 schema + 源码（可选）+ 至少 2 条执行轨迹（含成功/失败/边界）；操作：先用 GPT-4.1-mini 增强 Purpose/Guidelines/Limitations/Parameter Explanation/Length，再用 GPT-4.1 当 Jury LLM 从轨迹中提取 Examples 与 Limitations，最后拼成 5 字段 JSON 写回 PostgreSQL；输出：增强描述库；(5) 评估（§4.5）——输入：MCP-Universe 基准的 231 个任务、4 个模型（GPT-4.1、Qwen3-Coder-480B-A35B、GLM-4.5、Qwen3-Next-80B-A3B-Instruct）；操作：通过 Tool Description Router 切换 Original/Augmented/组件子集描述，运行 ReAct 智能体；输出：SR/AE/AS 三项指标，并用 McNemar 检验 SR、Wilcoxon 符号秩检验 AE/AS。
技术新颖性
技术新颖性主要体现在三方面：第一，**双层评分器架构**——上层 LLM-as-Jury 保证跨模型家族泛化（ICC 0.62–0.90），下层人工抽样（90 个工具，Weighted Cohen's Kappa 0.72–0.89）做金标准对齐，这种"机器打分+人类校准"的组合在工具描述领域尚属首次；第二，**接地增强管线**——通过抓取 Claude Desktop 与真实 MCP 服务器的执行轨迹（含 isError 标志）来构造忠实 Examples，避免了纯 Prompt 增强常见的幻觉问题，并通过 Wilcoxon 符号秩检验证实 Parameter Explanation 忠实度从 0.71 跃升至 1.00；第三，**客户端路由 + 协议扩展提议**——Tool Description Router 在不改任何服务器代码的前提下让 MCP 使用方按需切换描述或裁剪组件，作者据此向协议维护方提议把单文本 blob 升级为按组件结构化字段（Purpose/guidelines/examples 各自独立 JSON 字段），以便智能体根据上下文预算懒加载。这三处创新让"坏味道"概念在 LLM 工具调用场景中第一次具备了完整的"检测-修复-部署"工程闭环。
实验结果
RQ-1 发现 856 个 MCP 工具描述中 97.1% 至少含一种坏味道；按坏味道类型细分，Unstated Limitations 89.8%、Missing Usage Guidelines 89.3%、Opaque Parameters 84.3%、Underspecified or Incomplete 79.1%、Exemplar Issues 77.9%、Unclear Purpose 56.0%（图 7）。Table 4 揭示一个关键漏斗：单独看 Purpose 维度有 44.0% 的工具是 smell-free，但要求 Purpose+Guidelines+Limitations+Parameter Explanation+Examples 全部合规时只剩 2.9%。Table 5 显示官方与社区服务器在六个维度的中位数评分差异经 Mann-Whitney U + Bonferroni 校正后 p 值全部等于 1.00，表明低质量是生态级系统问题。RQ-2（Table 7、Table 8）显示增强全部组件在 4 模型 × 6 域 = 24 次运行中带来 5.85 个百分点（中位数）的任务成功率提升（McNemar 检验 p=0.02），AE 提升 15.12%（Wilcoxon p<0.01），但平均执行步数 AS 膨胀 67.46%（中位数，Wilcoxon p<0.001）；具体到 (模型, 域) 单元，54.17% 的组合 ΔSR>0（变好），29.16% 持平，16.67% 出现回归。最显著提升是 Qwen3-Coder-480B-A35B 在 Finance 域从 40.00% 跃升至 72.50%（+32.50 pp），最显著回退是同一模型在 3D Design 域从 26.32% 降至 21.10%（-5.22 pp）。RQ-3（Table 10、Table 11、Figure 12）的消融实验显示：(a) 不存在跨所有 (域, 模型) 组合的"黄金配置"；(b) Finance × GPT-4.1 上仅用 Purpose+Guidelines 两个组件就达到 67.50% SR，超过全增强的 57.50%；(c) 在所有 5 个 (域, 模型) 组合上，去掉 Examples 组件（Cochran's Q 检验 p>0.20）均未造成统计显著的 SR 下降；(d) FR（全增强）与 BC（最优组件子集）在任务层面的 Pearson χ² 检验 p<0.01、φ 系数 0.51–0.91，说明两者解题集合高度重合但非完全包含，存在"杂交运行"进一步提升 SR 的可能性（如 Location Navigation 杂交可达 37.8%）。Figure 11 的 Pareto 前沿进一步揭示一个反直觉结论：较小的 Qwen3-Next-80B-A3B-Instruct 在 Browser Automation、Financial Analysis、Location Navigation、Repository Management 多个域都落在帕累托前沿或附近，击败 Qwen3-Coder-480B-A35B 与 GLM-4.5 这两个 30 倍参数量的模型，说明模型规模并非效率的决定性因素。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| MCP-Universe 综合任务成功率（跨 6 域，4 模型） | 任务成功率 SR（所有 evaluator 通过的任务占比） | 中位数 ΔSR = +5.85 pp，McNemar 检验 p=0.02 | 原始 MCP-Universe 描述下的 SR（GPT-4.1 18.18%、Qwen3-Coder-480B-A35B 19.91%、GLM-4.5 24.68%、Qwen3-Next-80B-A3B-Instruct 15.58%） | 绝对提升 5.85 pp，相对提升约 24%–36%；但 16.67% 组合出现回归，最大回退 -9.09 pp（GLM-4.5 Web Searching） |
| MCP-Universe 评估器通过率（跨 6 域，4 模型） | Average Evaluator 分数 AE（任务通过的 evaluator 比例平均） | 中位数相对提升 +15.12%，Wilcoxon 检验 p<0.01 | GPT-4.1 0.41、Qwen3-Coder-480B-A35B 0.38、GLM-4.5 0.41、Qwen3-Next-80B-A3B-Instruct 0.33 | 全部 4 个模型 AE 均提升至 0.39–0.47 区间；17 个任务（中位数 7.36%）AE≥0.80 但 SR=0，表明增强帮助通过更多中间检查但仍受最大步数限制 |
| MCP-Universe 执行步数（成本代理） | 平均执行步数 AS（FM 调用次数） | 中位数相对增加 +67.46%，Wilcoxon p<0.001（3/4 模型显著） | GPT-4.1 5.24、Qwen3-Coder-480B-A35B 7.78、GLM-4.5 7.33、Qwen3-Next-80B-A3B-Instruct 9.46 | 3 个模型步数显著上升（最高 GPT-4.1 由 5.24→8.08），但 Qwen3-Next-80B-A3B-Instruct 反而从 9.46 降至 6.97，说明小模型+好描述可在不增步甚至降步的情况下提 SR |
| 工具描述组件级质量提升（增强前 vs 增强后） | 六维 Likert 5 分制中位数评分 | Purpose 2.0→5.0、Guidelines 1.0→5.0、Limitations 1.0→5.0、Parameter Explanation 1.0→4.7、Examples 1.0→5.0、Length 1.3→5.0；Wilcoxon 检验全部 p<0.001 | 原始描述六维中位评分 1.0–2.0 区间（详见 Table 6） | 全部六个维度均达到或接近 5 分上限；中位差 2.7–4.0 分 |
| 坏味道检测评分器一致性 | 组内相关系数 ICC(2,1) + Weighted Cohen's Kappa（人机） | ICC 范围 0.62（Examples）–0.90（Parameter Explanation）；人机 Kappa 范围 0.72（Guidelines）–0.89（Parameter Explanation） | 无既有基线可参考 | 5/6 组件达"良好"（0.75–0.9）、1/6（Examples）"中等"（0.5–0.75）信度区间；人机 Kappa 全部 ≥0.70 达到"实质性一致"阈值 |
| 源码接地对描述忠实度的提升 | 忠实度评分（0–1，来源支撑度） | 接地后中位数：Parameter Explanation 0.71→1.00、Limitations 0.86→1.00、Guidelines 1.00→1.00、Purpose 1.00→1.00；Wilcoxon p<0.001 | 无接地时各组件中位忠实度 0.71–1.00（Examples 维持 1.00） | Parameter Explanation 改善最大（r=0.81 大效应）；但忠实度提升未必转化为 SR 提升（McNemar p=0.064 无显著差异） |
局限与改进
作者在 §8 坦诚了四类有效性威胁，本人在此基础上补充几处观察。**外o有效性威胁**：数据集 856 工具全部来自已发表实证研究（4 篇），可能漏掉企业内部或最近出现的新型服务器；性能评估仅覆盖 MCP-Universe 的 202 个工具/18 个服务器子集，且因 token 成本（每轮 200–300M tokens、75–600 USD）未能重跑原 MCP-Universe 所有基线模型，使得 3 个模型的对比只能依赖聚合指标而非配对检验。**构o有效性威胁**：Score 3 作为"最小可行阈值"本身是主观选择，FM 打分对 prompt 措辞敏感；源码接地仅覆盖 Python/JS/TS/Go + OpenAPI 五种范式，PayPal 等闭源服务器无法接地。**内o有效性威胁**：智能体的非确定性可能放大或缩小观察到的差异；Web Searching 域为绕开 SERP API 配额改用 Google Search MCP 服务器，引入平台差异。**作者未充分讨论的局限**：(1) "气味的执行影响"研究中存在 16.67% 的回归案例，作者未深挖这些回归的根因（是 Examples 触发幻觉？是 Limitations 段落过长扰乱注意力？）— 这其实是后续最值得追问的方向；(2) Token 分析（Table 9）只在 Qwen3-Next 上跑、只覆盖 3 个域，且结果只显示方向不显示幅度；(3) Pareto 前沿图（Figure 11）依赖 AS 作为成本代理，但 AS 是离散整数，与真实 USD 成本的关系并非线性（不同模型 token 单价差 4.5×）。
独立分析的弱点
独立审视下，本研究暴露五个主要弱点并附改进方向。**(1) 量表的"最小可行阈值"硬编码为 3，缺乏校准实验**——目前 3 分是经验选择，但不同组件的最佳阈值可能不同（例如 Parameter Explanation 在 MCP schema 已提供类型信息的前提下，2 分可能就足够；Examples 由于存在"反效果"案例，可能应该设为 4）。改进方向：把阈值也作为超参数，在小规模 (域, 模型) 网格上做阈值敏感性分析。**(2) 接地增强对"流行工具"收益边际递减**——Table 14 的忠实度提升主要来自 Parameter Explanation，而 SR 提升（McNemar p=0.064）却不显著，因为 Yahoo Finance、GitHub 等流行工具已被 FM 在预训练中充分见过。这暗示研究应分层进行：对训练分布内的工具重在压缩，对长尾工具重在接地扩展。**(3) LLM-as-Jury 自身可能引入评估偏差**——本文虽然用三模型取均值缓解，但所选三个模型（gpt-4.1-mini、claude-haiku-3.5、qwen3-30b）全部经过类似 RLHF，对"清晰解释"的偏好可能同质化。改进方向：引入更长尾的开源基模（如 Mistral、DeepSeek）作为第四位评审，或用更接近 FM 推理过程的"隐式评分"（如在 ReAct 循环中直接观测模型选错工具的概率）替代显式 Likert 打分。**(4) 消融实验只覆盖 5 个 (域, 模型) 组合**——RQ-3 的结论"无黄金组合"和"Examples 可去除"虽然统计稳健（Cochran's Q p>0.20），但样本量太小（25 次运行）使得"未来泛化"承诺偏弱。改进方向：至少跑满 4 模型 × 6 域 = 24 个组合的消融，必要时降级 MCP-Universe 子任务以控成本。**(5) 16.67% 回归案例未做根因分析**——这是论文最大的"未解之谜"：为什么在 3D Design、Browser Automation、Web Searching 等域增强反而拉低 SR？本文给出了几种假设（如 Examples 触发幻觉、Limitations 段过长），但未量化归因。改进方向：对每个回归案例做"反事实干预"——只增删单一组件，重跑该案例，定位罪魁祸首组件。
未来方向
作者在 §7 已为四类受众（开发者/生态维护者/用户/研究者）勾勒了未来方向，本文判断最具突破潜力的延伸包括：(1) **组件结构化协议扩展**——把 MCP 当前的单文本 description 字段升级为 `{purpose, guidelines, limitations, param_explanation, examples}` 五字段 JSON，让智能体根据上下文预算懒加载；可借助 MCP 工作组推进。(2) **与新兴效率机制的交叉研究**——MCP Zero 的主动工具发现、Anthropic 的 Tool Search、Cloudflare/Anthropic 的 Code Mode 都在尝试"少装多算"，但都假设工具描述是静态的；研究 rubric-增强描述能否提升工具检索 recall 与代码生成正确率，是"好描述"能否成为这些机制"倍增器"的关键。(3) **Agent Skills 的元数据补全**——Claude Skills 等 progressive disclosure 机制常被报告"模型不主动调用"，作者怀疑根因正是元数据过于精简，可借鉴本文消融方法系统识别 Skill 元数据的"最小必要组件"。(4) **基于强化学习的自适应描述路由**——本文的 Tool Description Router 是静态切换，可升级为"运行时按 (用户查询、当前上下文预算、历史成功率) 自动选择描述变体"的策略网络；作者暗示的 FR+BC 杂交运行（在 Location Navigation 已展示 37.8% 潜力）是这种思路的雏形。(5) **跨语言、跨域的扩展**——本文 MCP 评估仅 6 域，建议把方法迁移到医疗、生物信息、具身智能等长尾 MCP 服务器，验证"坏味道 → 增强"管线的普适性。(6) **基于本文扫描器建设"MCP 描述质量 CI"**——模仿 npm audit 的设计，把评分器嵌入官方 registry 的 pre-publish hook，把 97.1% 的坏味道率作为生态基线、逐年追踪改进幅度。
复现评估
复现性整体较好但成本不可忽视。**开源情况**：作者在 §1 和 §4 中明确说明增强器、扫描器、Router、任务生成器、人机评估 prompt 全部发布在 GitHub（https://github.com/SAILResearch/mcp-tool-description-augmentation）；Table 6、Table 13 的 Wilcoxon 检验、Table 7/Table 8 的 SR/AE/AS、Table 11 的 Pearson χ²、Figure 11 的 Pareto 前沿都给出了统计方法与脚本链接；Tool Description Router 是对 MCP-Universe 客户端的明确扩展，可在不改服务器代码的前提下动态注入描述。**数据规模**：扫描阶段覆盖 856 工具/103 服务器，使用 3 个异构 FM 跑全量打分；增强阶段对 MCP-Universe 的 202 工具执行了全流程。**算力门槛**：根据 §4.5 披露，跑完 MCP-Universe 一轮约 200–300M tokens、75–600 USD 一次（取决于模型）；全增强 + 4 模型 + 6 域 + 消融实验的总成本粗估在数千美元量级——这意味着普通研究团队难以独立复现。**复现难度**：中等。增量门槛主要有三——(a) MCP-Universe 依赖 SERP/Google Maps 等付费 API，部分域需要 API key；(b) Web Searching 域需要切换为 Google Search MCP 服务器以避开 250 queries/月配额；(c) Qwen3-Next-80B-A3B-Instruct 等小模型的部署需要合适的 GPU。建议先复现 RQ-1（坏味道统计，无需 GPU）再视预算推进 RQ-2。
论文图表
展示基于 FM 的智能体通过 MCP 客户端调用工具的 4 步流程：(1) 客户端通过反射从 MCP 服务器请求可用工具定义；(2) 客户端将用户查询与所有工具的元数据（名称、描述、输入 schema）注入 FM 上下文，FM 据此规划并选择工具（如 get_financial_statement）填充参数；(3) 客户端执行工具调用；(4) 响应回传 FM，FM 综合最终答案。
这张图定义了全文核心论证的物理基础——FM 仅凭工具描述做出所有决策，因此描述质量成为决定性变量。读者若不先看懂这个回路，就无法理解后续"增强描述"为何能影响 SR。
对比同名的 get_historical_stock_prices 工具的两个描述版本：(a) 原始版仅笼统说"使用 period 参数或使用 start 和 end"，未把 start/end 列为正式参数名也未给日期格式；(b) 分叉版将 start_date 与 end_date 列为显式参数并注明 yyyy-mm-dd 格式。同一个 FM 智能体在 (a) 下会调用 period 拉取多年数据，在 (b) 下能构造精确时间窗。
这是论文"motivational example"的核心插图，用一个真实可复现的失败场景把抽象的"坏味道"概念锚定为具体的工程问题，是从动机过渡到方法的桥梁。
6 张子图对应 MCP-Universe 的 6 个域，每张画出 4 个模型在 AE（精度）-AS（成本）平面上的散点位置与 Pareto 前沿。在 Browser Automation、Financial Analysis、Location Navigation、Repository Management 上 Qwen3-Next-80B-A3B-Instruct 与 GPT-4.1 落在前沿附近，而 Qwen3-Coder-480B-A35B 与 GLM-4.5 多落在被支配区域。
这是论文最反直觉的图表——证明小模型+好描述可以匹敌大模型，是"工具描述是可调杠杆"这一论断的强力视觉证据。
5 张韦恩图（5 个域-模型组合），显示 FR（黄）与 BC（蓝）各自完成的任务集合及其交集（绿）。例如 Location Navigation × GPT-4.1：FR 与 BC 共享 9 个成功任务，但各有 8 个独特成功任务——构成"杂交运行可把 SR 推到 37.8%"的论据。
这张图回答了 RQ-3 最关键的开放问题："既然没有黄金配置，是否能组合配置？"——FR 与 BC 的高重叠度同时具备显著互异性，是未来"集成多描述"研究路线的视觉基础。
接地 BA vs 接地 AA：六维全部 p<0.001，r=1.00；Purpose 2.0→5.0、Guidelines 1.0→5.0、Parameter Explanation 2.0→4.7。
对 Table 6 的接地重做版，证明即便在更严格的接地评估下增强效果依然成立。
忠实度（0–1）UG vs WG：Parameter Explanation 0.71→1.00（r=0.81）、Limitations 0.86→1.00（r=0.86）、Guidelines 1.00→1.00（r=0.84）、Purpose 1.00→1.00（r=0.66）、Examples 1.00→1.00（p=0.47、r=-0.21，无显著差异）。
证明源码接地确实能减少幻觉（特别是 Parameter Explanation），但也展示了一个微妙反例：忠实度高不等于 SR 高——在工具广为 FM 训练数据覆盖的场景下，忠实度增益未必转化为执行增益。