精简 MCP 工具定义，降低上下文开销

一个 AWS MCP server，从 15 个工具缩到 4 个，作者宣称：同一个问题，Agent 原先要调用 7 次工具，精简后只需 1 次。文章想说明，工具多未必让 Agent 更能干，工具定义也会消耗上下文，增加选择负担。

这个方向值得做 AI 编程工具的程序员关注。不过，提供的原文只是教程开场，没有展开完整实验。我们能拿走的是一个优化思路，以及用 Kiro 的 /context 观察成本的方法，还不能据此认定「4 个工具」就是最佳配置。

为什么还没提问，上下文就被占了

作者指出，典型的 MCP server 可能在用户提出问题之前，就已经消耗了上下文窗口。

理解这件事，需要把工具本身和工具定义分开：Agent 要选择工具，通常需要先看到工具的名称、描述、参数等信息。这些内容也要进入模型可读取的上下文，并非只有聊天记录才占空间。

因此，接入更多工具，不只是多几个可选按钮，也可能增加每次任务开始时的信息负担。作者用同一个 AWS MCP server 的两个实现做对比，就是想把这种平时不容易察觉的开销展示出来。

工具数量值得检查，但真正要量的是工具定义占了多少上下文。

原文没有给出两个版本各自的 token 数，也没有说明描述长度、参数复杂度是否一致。因此，15 个工具和 4 个工具的差距，目前只能作为排查线索，不能直接换算成费用降幅。

从 15 个工具到 4 个，省下的可能还有选择过程

原文提到两类被 AWS 命名的问题：bloat 和 confusion，可以分别理解为工具膨胀，以及工具选择混淆。

前者关心「塞进去了多少内容」，后者关心「Agent 能不能选对」。这是两个不同的问题：即使工具定义不长，如果职责重叠、边界含糊，Agent 仍可能绕路。这是对两类问题的解释，原文并没有展示具体工具，无法判断作者的服务器究竟在哪些地方发生了重叠。

作者给出的演示对比很直观：

• 膨胀版本有 15 个工具，回答一个问题需要 7 次工具调用。
• 精简版本有 4 个工具，宣称用 1 次干净的调用完成回答。

这里的价值不只在于少调用几次。如果中间步骤确实多余，减少绕路也能让执行过程更容易理解。但调用次数不能单独证明答案质量，更不能直接证明总费用降低了多少：一次调用返回多少内容、模型消耗多少 token，原文都没交代。

作者预告视频会展示完整重建过程，并让读者在 Kiro 的 /context 中观察变化。当前提供的文字没有列出那 4 个工具，也没有展开页面导航中提到的「4 个修复」。具体怎样合并、删减或重新设计接口，尚无从判断。

我的判断

我赞同作者把 MCP 工具设计当作上下文设计来审视。给 Agent 接入能力时，不能只检查「能否调用」，还要看工具是否容易被理解和选择。

但这份材料更接近案例预告，还不是完整的成本实验。7 次对 1 次是作者描述的演示结果；缺少问题原文、模型配置、答案质量和重复测试，无法判断差异有多稳定。

相比直接把多个工具合成一个大工具，先删掉当前任务不需要的工具、澄清工具职责，也是可考虑的做法。合并过度可能只是把选择困难转移到参数里。作者没有给出这些方案的对照数据，因此「更便宜、更聪明」仍需结合实际任务验证。

值得借鉴的是减少无效选择的方向，而不是把 4 个工具当成目标。

能拿来做什么

• 如果你在 Kiro 中接入了 MCP server，可以先用 /context 查看提问前的上下文占用，再比较精简工具后的变化，保留实际观察结果。
• 如果你在为 Node 项目开发 MCP server，可以检查工具之间是否职责重叠、描述是否含糊，再决定删除、合并或改写，别只按工具总数优化。
• 给日常 AI 编程流程做对比时，可以固定同一个问题，同时记录工具调用次数、token 消耗和答案是否完成任务。原文的 7 次与 1 次适合作为观察维度，不能替代你自己的验证。