MCP工具设计实践：避免上下文膨胀与模型混淆的工程方法

一句话看懂

AWS工程师总结MCP工具设计常见失败原因：直接暴露API而不做上下文工程，导致上下文膨胀和模型混淆，并提出6种优化策略。

详细发生了什么

Model Context Protocol (MCP) 工具表现不佳，根源往往不在协议本身，而在工具设计。许多团队直接将现有API暴露给Agent，期望模型自行处理。这在简单场景下可行，但多数情况会导致工具调用失败、参数错误、重试浪费上下文。

AWS工程师Daniel Wells指出两大核心问题：膨胀（bloat）——工具定义每次调用都加载到LLM上下文，多个MCP服务器在用户提问前就消耗大量上下文；混淆（confusion）——上下文膨胀导致推理能力下降，模型选错工具或填错参数，重试进一步加剧膨胀。

文章以K-12教育资源搜索API为例，展示了6种MCP工具设计版本，从原始透传到完全Agent化，逐步解决上述问题。关键方法包括：优化描述与错误信息、使用枚举和默认值约束schema、拆分多功能工具、懒加载工具定义（Anthropic报告可减少85% token）、服务端推理（introspection tool）以及完全Agent化工具。

中文圈视角

对国内开发者而言，MCP工具设计问题同样普遍。许多团队在接入DeepSeek、Kimi等国产模型时，也面临类似挑战——直接暴露API接口，忽略上下文工程。

实用建议：

• 国内用户可参考AWS的schema约束方法，在工具定义中多用枚举（enum）和默认值，减少模型猜测。
• 懒加载策略尤其适合资源受限场景：将复杂工具描述移出常驻上下文，仅按需加载，可显著降低token消耗。
• 服务端推理（introspection）思路值得借鉴：用一个专门的小模型解释用户意图，再调用实际工具，适合对准确性要求高的场景。

国产替代参考：

• 类似MCP的协议，国内有百度千帆的Plugin机制、阿里百炼的Agent框架，但工具设计原则相通。
• 对于没有MCP客户端的团队，可直接参考文中思路优化自家Agent工具的prompt设计。

盲点提醒：中文圈讨论MCP时多关注协议本身，较少深入工具设计细节。本文的“上下文工程”视角填补了这一空白。

几条值得记住的细节

• 工具参数数量建议控制在8个以内，超过则考虑拆分。
• 错误信息应具体指导修正，如“搜索需要至少2个词”，而非简单返回“无结果”。
• 参数命名应贴近领域自然语言，而非数据库字段名（如用resource_class而非content_bucket）。
• Anthropic的Tool Search Tool通过懒加载实现高达85%的token减少。
• 服务端推理工具使用较小、较快的模型即可，成本可控。

一句话总结

设计MCP工具时，优先考虑上下文工程：精简描述、约束参数、按需加载，才能让Agent高效工作。