为什么我们拒绝了节省 96% Token 的方案

我们发现了一个可以节省 96% Token 的 MCP 服务器。它只使用一个工具：execute_code。代理（agent）不再调用特定的函数，而是通过编写 JavaScript 来获取数据。

从理论上看，它胜出了。对于复杂任务，代码执行在效率上优于工具调用。

但我们并没有采用它。相反，我们保留了离散的、具名（named）的工具。

以下是为什么这个显而易见的方案对我们的代理来说是错误选择的原因。

目标决定设计

大多数人是为聊天窗口中的前沿模型（frontier models）进行构建。这些模型拥有巨大的 Token 预算。对它们而言，代码执行是王道。

而我们是为在船上的小型本地模型（Hermes 3 8B）构建语音优先的代理。

对于小型模型，约束因素不是 Token，而是可靠性。

如果一个小型模型在调用简单工具时都感到吃力，那么要求它编写正确的 JavaScript 则是一项艰巨得多的任务。execute_code 是以可靠性换取 Token。我们承担不起这种代价。

“最后一公里”问题

代码执行将“最后一公里”的工作推给了代理。代理必须：

• 过滤数据
• 对结果进行排序
• 格式化输出

我们的工具在服务器内部完成这些工作。例如，在询问电池状态时，我们的工具会返回一个可以直接用于文本转语音（text-to-speech）的字符串。它会说“68%，12.8 伏”，而不是原始数字。

如果我们使用 execute_code，代理必须编写逻辑来格式化这些语音。小型模型在这一点上经常失败。

缺失规则

在船上，传感器会掉线。在我们的系统中，缺失的传感器会返回一个干净的 null。这被视为一次成功的调用。

在代码执行模型中，缺失的传感器通常会抛出错误。如果小型模型尝试了几条错误的路径，就会触发错误限制并导致代理崩溃。具名工具允许我们将“缺失”视为一种成功，而非故障。

采用 vs. 构建清单

在你采用或构建 MCP 服务器之前，请询问以下问题：

• 目标代理是谁？（前沿模型 vs. 小型本地模型） • 核心约束是什么？（Token vs. 可靠性） • 谁来完成“最后一公里”？（是工具格式化数据，还是代理进行格式化？） • 如何处理缺失值？（缺失值是错误还是 null？） • 维护成本是多少？（你是否在继承一段停滞不前的代码库？）

我们并没有忽视那个项目。我们汲取了它的想法。我们借鉴了他们的报警处理和路径发现逻辑，并将其加入了我们的路线图。

效率固然重要，但在海上航行时，可靠性才是必需的。

Source: https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae

Optional learning community: https://t.me/GyaanSetuAi