作者发现AI代理使用MCP协议时会因加载完整工具目录而浪费资源，转而采用CLI方案。通过CLIHub将MCP服务器转为CLI接口后，改为按需加载工具详情而非初始全量加载。测试显示6个MCP服务器共84个工具的场景下，CLI方案将成本降低了94%，主要节省了初始会话时的令牌消耗。

标题：我用一条命令将MCP成本降低94%

核心内容： 1. 问题发现 - 当前AI代理使用MCP协议时，主要成本浪费在工具目录加载环节 - MCP会一次性加载所有工具的完整JSON Schema（平均每个服务器14个工具，6个服务器共84个工具） - 初始会话加载量高达15,540个token（185token×84工具）

2. CLI解决方案

• 通过CLIHub将MCP服务器转换为CLI接口
• 初始会话仅加载轻量级工具列表（6个服务器共300token）
• 工具调用时通过--help命令动态获取详情（约600token）
• 总体token使用量减少94%

3. 性能对比 | 使用场景 | MCP消耗 | CLI消耗 | 节省率 | |----------------|---------|---------|--------| | 会话初始化 | 15,540 | 300 | 98% | | 调用1个工具 | 15,570 | 910 | 94% | | 调用10个工具 | 15,840 | 964 | 94% | | 调用100个工具 | 18,540 | 1,504 | 92% |

4. 与Anthropic方案对比

• Anthropic的Tool Search方案仍比CLI多消耗74-88%的token
• CLI方案兼容所有模型，更具通用性

5. 实现方案

• 开源CLIHub转换工具（GitHub可获取）
• 单条命令即可将MCP服务器转为CLI接口

技术细节： - CLI采用类似Openclaw的available_skills块格式 - 工具发现分两步：先获取基础信息，需要时再加载详情 - 动态加载机制显著降低初始负载

（注：已剔除原文中的图片引用、脚注标记等非核心内容，保留关键数据对比和技术实现要点）

以下是评论内容的总结：

主要观点和争议

1. MCP工具的效率问题

• 观点：MCP工具描述冗长，占用大量上下文窗口，导致效率低下。
  • 引用："MCP tools are sent on every request... This is going right into the context window." (pdp)
  • 引用："The real killer is the input tokens on each step... You're sending 1-5M input tokens." (OsrsNeedsf2P)

2. CLI工具的优越性

• 观点：CLI工具更简洁、可组合，且适合LLM使用。
  • 引用："Even the smallest models are RL trained to use shell commands perfectly." (cmdtab)
  • 引用："CLI-based approach is scriptable... Coding assistant will typically pipe the tool in jq or tail." (pdp)

3. 工具发现与上下文管理

• 观点：工具发现机制（如Skills）可以避免上下文膨胀。
  • 引用："MCP tools can (and does in Claude Code) work the same way." (philfreo)
  • 引用："Skills were designed to be searchable without dumping everything into context." (philfreo)

4. 状态管理与审计

• 观点：CLI工具更易于审计和权限管理。
  • 引用："CLIs naturally leave a trail you can replay." (orliesaurus)
  • 引用："The permission boundary is clearer. You can whitelist commands, flags, working dir." (orliesaurus)

5. 未来架构的思考

• 观点：应关注语义空间的压缩和分层，而非单纯工具暴露。
  • 引用："Ultimately, shouldn't the core question be less about 'how do we expose fewer tools,' and more about 'how do we layer and compress the semantic space?'" (eggplantiny)
  • 引用："The direction I'm exploring is... normalizing the semantic primitives above them." (eggplantiny)

6. 技术实现的争议

• 观点：MCP与CLI的优劣取决于具体场景和实现。
  • 引用："Is there any redeeming quality of MCP vs a skill with CLI tool?" (cheriot)
  • 引用："I suspect this might be why cursor likes writing bash scripts so much." (foota)

其他提及

• 链接问题：文章中的clihub.sh链接已失效，正确链接为clihub.org (dang)
• 工具比较：有人提到MCPorter和mcpshim等工具，探讨其差异和优势 (mijoharas, pdp)
• AI生成内容：有评论指出文章可能是AI生成的 (slopinthebag)

总结

评论中普遍认为CLI工具在效率、可组合性和审计方面优于MCP，但也有人指出MCP的最新实现（如Claude Code）已通过工具发现机制解决了上下文膨胀问题。未来可能更需关注语义空间的优化而非单纯工具选择。