LLM within MCP Matters: Measuring Inefficient Resource Utilization Driven by LLMs
Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han
cs.AI, cs.CL, cs.IR
2026-08-09
5.4 万次实测:搜索工具一在场,9 个模型就无视 MCP 指令缓存表,命中率跌破 15%;拿掉搜索后 23 个读到 98% 以上,属行为偏好而非能力缺失。
MCP（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年提出的标准,规定外部数据源和工具如何标准化地暴露给大模型。Claude Desktop、Cursor 这类 host 应用连接到各个 MCP server,后者通过三条通道暴露能力:Resources(按需拉取的结构化数据)、Tool schemas(可调用的函数)、以及 Server instructions(写给模型看的 system prompt 文本)。
一个常见的设计模式是:server 把高频用到的查表数据直接塞进 instructions。比如一个法律信息 server,会把最常被查询的 20 部法律和它们的 ID 列成一张表(「民法 → 001706」)。模型查民法时本该直接用缓存好的 ID 调一次服务就完事,省掉先搜索、再拿 ID 的那一轮。问题是,模型真的会读这张表吗?还是会不假思索地调搜索工具,把已经写在眼前的答案又找一遍?
这篇论文测的就是这件事,而且发现这个问题严重到算得上一类隐形成本。
测试床是 LexLink,一个真实在线的韩国法律信息 MCP server,暴露 26 个工具。查一部法律本来要走两步:先用 eflawsearch 把查询映射到法律 ID,再用 eflawservice 按 ID 取全文。LexLink 在 server instructions 里嵌了一张表,列出 20 部最常被查的法律及其 ID。对于这 20 部法律里的任何一部,效率最高的做法是跳过搜索,直接 eflawservice(id="001706") 拿内容。
衡量指标叫命中率 φ:在一次试验里,模型的第一个工具调用是不是带着正确缓存 ID 的 eflawservice。调了搜索、调错 ID、任何其他首调都算 miss。
作者跑了 24 个模型,9 个 Claude、6 个 Gemini、9 个 GPT,跨多个代际和能力档。每个模型跑 9 个条件:8 个来自三条指令级干预的 2³ 全因子组合,再加一个诊断条件。三条干预是:
第九个条件 nos 干脆把 eflawsearch 整个拿掉,只留指令表。5 条查询、每条 50 轮,24 模型 × 9 条件 × 5 查询 × 50 轮,总共 5.4 万次试验。每个格子汇 250 次,95% 二项置信区间半宽不超过 ±6.2 个百分点。
最锋利的一刀来自 nos 诊断条件。搜索工具拿掉之后,24 个模型里有 23 个命中率不低于 98%(其中 22 个不低于 99%)。几乎所有模型都读得懂这张表。唯一的例外是 gpt-4.1-nano,nos 下也只到 54%,属于低端模型真实的能力短板,而非单纯偏好。
可一旦搜索工具摆回去,baseline 命中率从 0% 一路散到 100%,有 9 个模型跌破 15%。搜索工具只是「在场」,没改指令、没改数据,就足以让模型放弃读已写在眼前的答案。作者把这种失败模式叫「行为偏好」,区别于「能力缺失」。
这件事并不随模型代际单调变好:
| 家族 | 上一代 baseline | 当代 baseline |
| GPT | 4.1:99% | 5:1% |
| Gemini | 2.5-pro:100% | 3-pro:2% |
| Claude Opus | 4.5:100% | 4.6:63% |
模型更新并不等于资源用得更省。作者只能推测原因:如果后训练在 agent benchmark 上奖励「成功调到匹配的工具」,就会训出「看到匹配工具就调」的策略;各厂商对 system-prompt 内容的加权不同,又能解释为什么这种退化按家族发生。要拆开这两个假设,需要厂商不公开的训练细节。
因子分析里,B 和 C 的平均主效应几乎一样(各 +19.9 和 +19.8 个百分点),但跨模型方差极大(标准差约 24 个百分点),因为它们各管一群模型:B 对 GPT-5-nano 最管用(+80.9),C 对 GPT-5.2 最管用(+85.6)。单因子还会反噬,GPT-5.2 单加 B,命中率从 5% 掉到 0%,可 B 和 C 一起加又拉回 100%。一次只动一个因子的实验设计根本看不出这种交互。三个全加(BCD),24 个模型里有 20 个能到 ≥86%。
全表满分、9 个条件全打满的有四个模型:cl-sonnet-4、cl-sonnet-4.5、cl-haiku-4.5、cl-opus-4.5。
这篇对三个群体都有直接结论。
对做 MCP server 的人:few-shot 示例(C)对网格里每一个模型的主效应要么是正的要么可忽略,是最安全的单点改动;单独加指令(B)可能救一个模型坑另一个。要覆盖最广就把 B、C、D 三个都叠上。但这些都是 per-server 的补丁,脆。
对做 host 应用(Claude Desktop、Cursor 这类)的人:真正该修的是 host 侧。论文主张 host 应该提供一个显式机制,把 server instructions 钉在模型选工具之前的推理步骤里,比如预注入为系统优先指令,或在每次选工具前强制查一次指令。
对评估 MCP server 能力的人:一个 server 的有效能力不仅取决于它自己怎么暴露数据,还取决于跑它的 client LLM 是谁。能力评估要和 client 环境一起报。
作者自己列了几条。所有证据来自单一 server、单一领域(韩国法律)。一个扩展研究计划在另外四个 server(地理、学术、数据库、消息)上复现,并测一个 host 侧的缓解方案,初步结果和这里一致,但论文把它当展望而非证据。
指标只量「第一次调用」的效率,没量端到端任务是否成功;好在这个测试床上一次调用对了就直接取到目标法律,两者重合。所有试验都是单轮,多轮 agent 可能自行纠正,只是多花 token 和延迟。B、C、D 各自只是某一种具体措辞,测出的效应绑在这次实例上,不绑在它们的类别上。最后,结论只覆盖「搜索纯属多余」的查表式工作流,搜索本身有信息量的任务不在范围内。
另有一处存疑:作者把 9 个模型的低命中归因为「行为偏好」,并坦承没法区分这是训练偏置还是一种理性的、对可验证工具输出的偏好,两者对资源消耗的实际后果一样。这个坦诚是对的,但也意味着「为什么偏好」这条因果链整篇都没真正合上。