MCP工具返回值格式实测：72次试验对比摘要行与原始时序数据

关于 MCP 工具应该返回什么数据，我跑了 72 次试验而不是打嘴炮

关于 MCP 的争论正在热烈进行中。你大概见过：一个 400 多点的帖子叫「MCP 已死？」，里面给出了真实的 token 数量——四个关联的服务器在任何人提问之前就吃掉了 21,077 个 token 的上下文。争论的焦点是 MCP 的成本。但几乎没人真正测量过 Agent 拿到工具返回的数据后会做什么。

我最终做了这个测量，不是因为我计划这么做，而是因为一位维护者拒绝让我靠猜。

没人愿意用观点来回答的问题

我为 CNCF Jaeger 的 MCP 服务器做贡献。去年四月，我提议将服务性能指标（延迟、调用率、错误率）作为 MCP 工具暴露出来，结果立刻遇到了一个设计分歧：输出应该是什么形状？

方案一，汇总行：每个服务预聚合的统计量，紧凑、廉价。方案二，按桶的时间序列：原始数据点，默认分辨率下每个服务大约 720 个，昂贵但完整。

我问维护者倾向哪个。issue 线程里的原话是这样的：

这类决策不应该基于观点，而应该基于基准测试——用真实的 Agent 排查一些问题，使用这个 MCP 工具访问指标，对不同输出格式做 A/B 测试。

说得在理。于是我搭了这个 A/B 测试框架。

下面所有内容都公开在 jaeger-mcp-bench 仓库里，包括测试框架、任务、评分器和一份研究日志，记录了所有出问题的地方。

测试环境是 Jaeger v2 配合 spanmetrics 连接器、hotrod 生成流量、后端是 Prometheus，做了快照以确保每次运行看到相同的指标状态。在指标 API 前面是一个薄薄的基准服务器，只有一个开关：--format=summary|series。没有新的语义，只是返回数据的形状不同。

六个排查任务，这一点很重要：我选了三个因为预测汇总会赢的任务（点查询：当前延迟、排名、阈值检查），还有三个因为预测序列会赢的任务（时间问题：尖峰检测、关联分析、趋势）。让任务同时对两个方案都有利，保持了实验设计不会对自己的假设偏心。

两个 Agent，不是精简版的工具循环：通过 Claude Code CLI 的 Claude Sonnet 和通过 gemini CLI 的 Gemini 2.5 Pro，用的是真实的 system prompt，因为生产环境中的 Agent 就是这样的。每个单元跑三次，72 次试验总计，单元按随机顺序运行（seed 42），这样测试环境漂移不会跟任一方案关联。评分是程序化对照真值的，不是凭感觉。

我预期的结果是错误答案。格式不对，结论错误，Agent 表现丢人，当个乐子看。

但事实并非如此。72 次试验里只有一次真正的错误结论，而且追溯到我自己的基准服务器的一个 bug，不是格式的问题（在 RESULTS.md 里披露了；它对汇总方案不利，我宁愿报告自己的 bug 也不愿造一个假发现）。

真正的差异在于拒绝率。给汇总行时，Agent 说「我无法从现有数据中判断」这种话的频率是给序列时的七倍，而且几乎全集中在时间问题上。而且他们拒绝得对：聚合破坏了问题所依赖的时间轴。你无法从平均值里定位一个尖峰。

Agent 吃得不够时不会给错答案。他们会礼貌而正确地放弃。

统计数据经过校正依然成立：Claude 的汇总对序列差距经过 Bonferroni 校正后是显著的（p=0.001，alpha 为 0.0125）。Gemini 的 p=0.016，刚好卡在边界上，我宁愿如实说也不愿意四舍五入往自己有利的方向靠。点查询结果一致，正如预测：当问题只需要一个数字时，格式不重要。

所以序列赢了。但这并不是有用的教训

工具最终按每个桶的序列数据发货，有数据支撑而不是凭我的审美。好。

有用的教训是关于「昂贵的输出」实际上买到了什么。整个 MCP 成本争论把 token 当作浪费：大响应坏，小响应好。基准测试说两者的关系比这更具体。紧凑格式在删除问题所依赖的那个轴之前是很便宜的，而一旦删除，它付出的代价就不是 token 了，而是 Agent 直接拒绝回答。一个「无法判断」会让你失去整个调查循环，加上重试成本，再加上 Agent 耸肩时人类接手做的那部分。

换句话说：序列输出的 token 账单是可见的，投诉起来很容易。汇总输出的失败账单是不可见的，除非你测量拒绝率，而没有人会测量拒绝率。

如果你现在正在设计一个 MCP 工具，可迁移的版本是这样的：

让格式匹配问题类别，而不是匹配 token 预算。点查询可以接受聚合。时间相关和因果相关的问题不行。

关注拒绝率，而不只是错误率。模型失败时很体面。你的错误仪表盘看不到这个。

用你自己的预测来平衡基准测试，否则你会搭建一个偏向你已有信念的牌桌。

当你的基准测试产生一个你喜欢的结论时，先找 bug。我的就有一个，而且它正好对赢的那方有利。

七十二次试验是每个单元三次。两个模型家族、一个测试环境、六个任务，全在可观测性领域。这能确定一个 tracing 后端里的指标工具应该返回什么格式；但并不能解决 MCP 的哲学问题。如果你用这个框架跑其他领域，我真心想看数据，所有需要的东西都在仓库里。

维护者是对的，这是简版结论。格式决策用了一个周末做基准测试，而本来可能会无休止地争论下去，永远得不出结论。

我做这个工作是有偿的，主要让 LLM Agent 在生产基础设施上更安全、更可观测。服务范围和定价在 roshansingh.systems/#hire，或者写邮件到 inbox@roshansingh.systems，告诉我你的 Agent 在折腾什么。