MCP协议真的过时了吗？实测数据告诉你：上下文占用大、可靠性低、不如直接用CLI

Anthropic推出的MCP（Model Context Protocol）曾被称为”AI生态的USB-C”，但实际使用它的开发者开始发现严重问题。Quandri团队的实测数据显示：MCP严重浪费上下文窗口、性能比CLI慢3-9倍、而且大多数场景下直接调用API更高效。

MCP的核心问题

问题一：吞噬上下文窗口

上下文窗口是LLM的”桌面”。当你连接MCP服务器时，光是工具定义就占用了大量空间。Quandri团队实测了他们的环境：连接4个MCP服务器后，10.5%的上下文窗口被工具定义占据。

其中Linear一个工具就占了超过12800个token，包含42个工具定义。即使你只用其中的get_issue和save_issue两个功能，其他40个工具定义也会一直占用上下文。

问题二：性能差

原文章作者对Jira MCP进行了基准测试，发现MCP每次调用比直接REST API慢3倍，首次调用（包括初始化）慢9.4倍。

更关键的是token消耗对比：查询同一个Linear issue，MCP消耗的token是CLI方式的约65倍。CLI方式只需要约200个token，而MCP需要数千个。

问题三：与现有工具重叠

MCP本质上是给LLM提供工具调用能力，但LLM已经可以通过CLI和API做到同样的事情。LLM已经从man pages和StackOverflow中学到了如何使用命令行工具，MCP只是多了一层不必要的抽象。

替代方案

方案一：CLI优先策略

直接给LLM提供CLI工具和API文档，让它通过命令行完成任务。优势：

• token消耗极低（约200 vs MCP的数千）
• 没有额外的服务器进程
• 调试简单，可以直接在终端复现
• LLM已经熟悉命令行范式

方案二：Skills模式

Skills模式是”按需加载”的思路。如果说MCP是”把所有菜单摊在桌上”，Skills就是”只向图书管理员要你需要的那本书”。

Skills只在需要时加载相关工具定义，而不是一开始就加载所有工具。这大幅减少了上下文占用，同时保留了结构化的工具调用能力。

MCP的适用场景

尽管有这些问题，MCP并非完全没有价值。在以下场景中，MCP仍然是合理的选择：

• 数据库查询：SQL工具的schema定义相对固定，MCP的结构化查询能力有价值
• 复杂多步工作流：需要多个工具协同的复杂场景，MCP的协议层提供了统一接口
• 非技术用户：对于不熟悉CLI的用户，MCP提供了更友好的工具发现机制

对站长的建议

作为站长和开发者，在选择AI工具集成方案时：

1. 优先考虑CLI/API：对于大多数场景，直接给LLM提供CLI工具和API文档更高效
2. 按需加载：如果必须用MCP，选择支持按需加载的实现，避免一次性加载所有工具
3. 监控token消耗：定期检查工具定义占用的上下文比例，超过10%就应该优化
4. 混合策略：简单任务用CLI，复杂工作流用MCP，不要一刀切

更新：Claude Code的改进

值得注意的是，Claude Code最近推出了Tool Search with Deferred Loading功能，按需加载MCP工具schema，减少了85%以上的上下文占用。这说明社区已经意识到了MCP的上下文问题，并在工具层面进行优化。

本文参考来源：Quandri Engineering – MCP is dead. Long live the CLI