常见的上下文工程陷阱与权衡

在实际项目中，把现有 API 原样暴露为 MCP 工具是很常见的做法，简单场景下也能工作。然而，一旦模型行为变差，原因往往不在协议，而在于工具描述、参数命名、返回体设计等细节。问题的根源通常可以归纳为两类：臃肿与混乱，二者常相互放大，使会话效率快速下降。

臃肿指工具定义会在每次调用时进入模型的上下文，无论最终是否被用到。当多个 MCP 服务器同时连接时，仅仅是元信息就会消耗大量 token，使模型推理能力逐步退化。混乱则体现在语义相近的工具、过多选项或名称歧义带来的误选，错误参数又会引发后续重试，进一步加重臃肿。

改进工具描述是最直接的手段：明确参数含义、补充自然语言映射和示例，可以缓解混乱。但每加一行说明都会增加上下文负担，因此需要把握平衡。返回结构同样关键，若一个结果默认返回 50 个字段而实际决策只需 5 个，应将详细字段设为按需请求，参考 Anthropic 的研究可降低约三分之二的响应 token。

Schema 层面的约束可以进一步去掉模型的猜测空间：用枚举限定取值、为高频参数设置默认值、将参数名改为模型更容易理解的领域术语，并删除使用率低或难以正确填写的字段。AWS Prescriptive Guidance 建议每个工具的参数控制在八个以内。

对于多功能复合工具，可以拆分为多个职责单一的小工具，并引入“惰性加载”的发现工具，仅在需要时拉取完整描述。Anthropic 的 Tool Search Tool 与 Bedrock AgentCore Gateway 在大规模场景下已证明该思路，按需加载工具定义最高可减少 85% 的 token。Skills 是一种客户端侧的惰性加载方案，但存在加载时机和版本一致性方面的隐患。

如果你无法控制调用 MCP 的客户端模型，可以为服务器增加一个自省工具，由你选定的小模型先解析需求，再把准确的参数和指令回传给客户端。若仍不够，最终方案是把整个 MCP 服务器背后挂上一个自有的智能体：客户端只需用自然语言表达意图，由代理完成其余工作，从而获得更高的准确性和完全的控制力。

要点

• MCP 工具表现不佳的根因通常不是协议，而是臃肿（上下文膨胀）与混乱（工具/参数误选）相互放大。
• 优化描述与返回结构能缓解混乱，但描述越长臃肿越严重，需要把握平衡。
• Schema 层面的约束效果显著：枚举、默认值、参数命名优化、参数数量控制在八个以内。
• 拆分工具并采用惰性加载（如 Tool Search Tool、Bedrock AgentCore Gateway）可大幅减少 token 消耗。
• 无法控制客户端模型时，可在服务器侧增加自省工具或直接接入自有代理，把部分推理控制权收回。