当模型上下文协议（MCP）工具表现不佳时，原因往往不在协议本身，而在于工具设计。许多团队直接暴露现有API，期望智能体自行处理其余部分，但这常导致工具调用失败、参数错误及重试，浪费上下文并降低性能。本文分析了这些失败背后的两大问题——臃肿与混乱，并提出了通过上下文工程优化的实用方法。
臃肿指工具定义在每次调用时加载到LLM上下文，即使未使用也会消耗资源。多个MCP服务器连接后，用户尚未提问上下文就已填满，影响推理能力。混乱则源于语义相似的工具、过多选项及命名模糊，使LLM选择错误工具或参数。常见做法是丰富工具描述，但这又会加剧臃肿。
为解决这些问题，文章介绍了多种策略。首先是改进描述和响应：清晰定义字段含义，提供自然语言映射，并优化错误消息。其次是采用模式约束：重命名参数以匹配LLM理解，使用枚举限制有效值，设置默认值，减少参数数量。AWS建议每个工具的参数不超过八个。第三是重构工具和延迟加载：将多功能工具拆分为专用工具，并仅按需加载上下文，可减少高达85%的令牌消耗。第四是服务端推理：通过自选LLM的“内省工具”解释用户自然语言查询，返回精准指令。最后是代理工具：完全由自己的代理处理整个交互，将工具变成自然语言端点。
文章随后通过一个模拟的K-12内容搜索API的六个版本进行了实际对比。该API有14个可筛选字段，LLM需将教师的口语化请求映射到精确值。V1为原始回传，参数名称内部化且无指导，导致频繁重试。V2改进描述，列出有效值和同义词映射，准确性提升但定义更臃肿。V3重命名参数并使用枚举和默认值，防止错误值。后续版本进一步应用延迟加载、服务端推理和代理工具。测试表明，在减少上下文消耗和提升首次调用准确率方面，延迟加载和模式约束效果显著。
总之，MCP工具设计需要平衡臃肿和混乱，根据具体场景选择合适的策略。本文提供的六种方法及对比代码可帮助开发者评估不同设计的实际效果。