糟糕的MCP设计导致您的代理消耗了5倍的代币
一句话看懂：一项针对两个功能相同的待办事项 MCP 服务器的对比测试显示，糟糕的接口设计会让 AI 代理在执行相同任务时消耗近 5 倍的输入代币，根本原因在于工具返回了过多无用数据，以及工具数量过多导致模型决策负担加重。
事件核心：发生了什么
开发者 Code-MonkeyZhang 分别编写了一个自定义 MCP 服务器（MCP-A）和一个官方发布的 MCP 服务器（MCP-B），两者后端 API 相同，功能覆盖也一致。通过 40 个典型使用场景的测试发现，尽管两者通过率均为 90%（36/40），但 MCP-B 的总输入代币消耗高达 3,174,329，是 MCP-A（637,244）的 4.98 倍。MCP-B 还多执行了 35 次 ReAct 循环，导致输出代币增加 34%，整体耗时多出 79 秒。
问题根源在于工具返回数据的设计。例如，MCP-B 的搜索工具返回的是只包含 ID、标题和 URL 的 JSON 切片，缺少后续 CRUD 操作必需的 project_id 字段，迫使代理额外调用 get_task_by_id 工具。MCP-A 则在一次查询中返回全部所需字段，包括项目 ID、优先级、状态等。更严重的是，MCP-B 的 create_task 工具直接传递原始 API 返回的 600 多字符 JSON——包含大量对代理任务无意义的字段（如 createdTime、focusSummaries），而 MCP-A 做了数据过滤与格式化。此外，MCP-B 的工具数量也更多：47 个工具未经有效合并，MCP-A 将其压缩至 14 个。
为什么重要
MCP（Model Context Protocol）是连接 AI 代理与外部工具的关键协议。此测试揭示了一个容易被忽视的性能瓶颈：MCP 的接口设计质量直接影响 LLM 的输入代币消耗和推理效率。在 API 成本高昂的背景下，差的 MCP 设计不仅浪费代币（输入成本增加 5 倍），还因增加不必要的 ReAct 循环而降低响应速度。这对 AI 应用的商业化落地和用户体验都有实际影响——一个设计良好的 MCP 能帮助企业节省数倍的计算成本，而糟糕的设计则可能让一个本可轻量完成的任务变得臃肿低效。
对用户/开发者/创作者的影响
对于开发者，测试提供了三条实用原则：
1. 工具应返回足够上下文，让代理能直接执行下一步操作，避免多次往返调用；
2. 尽量减少 MCP 内的工具数量，避免功能重叠，以降低模型的选择难度；
3. 对 API 返回数据做过滤和格式化，使其对 LLM 可读（如文本形式优于原始 JSON），而不是一股脑传递无用字段。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对于使用 AI 工具的用户而言，这意味着你使用的 Agent 应用可能在看不见的地方浪费了大量代币。如果你或你的团队正在编写 MCP 服务器，这些优化点能直接影响服务成本。测试作者已将基准测试工具 MCP-Eval 开源，供开发者检查自己的 MCP 性能。
值得关注的后续
1. MCP 生态是否会因这份测试而推动更规范的接口设计指南？目前 MCP 仍处早期阶段，缺乏像 RESTful API 那样的最佳实践标准。
2. 更多 MCP 开发者是否会采纳“上下文预判”设计思路，在工具返回中主动补全下游操作所需字段？
3. 模型厂商是否会在系统提示或微调中增加对“compact + 可读返回”的偏好，从而自动惩罚此类浪费代币的设计？
