MCP已死？Quandri工程团队深度解析模型上下文协议的局限性

核心要点

• 上下文占用过高：MCP服务器的工具定义会消耗大量Token，实测在Quandri环境下，四个常用服务器占用了10.5%的上下文窗口。
• 可靠性与重叠问题：开发者发现MCP在实际运行中可靠性较低，且其功能与现有的CLI（命令行界面）和API存在显著重叠。
• 实测数据支撑：Linear、Notion、Slack和Postgres四个MCP服务器共计77个工具，产生了约84,308个字符，折合超过2.1万个Token。
• 技术补丁的局限性：虽然Claude Code推出的“延迟加载”技术减少了85%以上的上下文占用，但并未解决性能和架构层面的核心争议。

详细分析

上下文窗口的“吞噬者”

在AI开发中，上下文窗口被形象地比喻为LLM的“办公桌”。MCP（Model Context Protocol）旨在将LLM连接到GitHub、Notion和Slack等外部工具，但其实现方式却给这张办公桌带来了沉重负担。Quandri的后端工程师Chloe Kim指出，仅仅是连接这些MCP服务器，其工具定义本身就会占据办公桌的巨大空间，导致处理实际任务的空间被大幅压缩。

根据Quandri工程团队的实测，他们在其环境中连接了四个主流MCP服务器，结果令人吃惊：

• Linear：包含42个工具，占用约12,807个Token。
• Notion：包含14个工具，占用约4,039个Token。
• Slack：包含12个工具，占用约3,792个Token。
• Postgres：包含9个工具，占用约438个Token。

总计77个工具定义共消耗了21,077个Token。这意味着在对话尚未开始前，LLM的认知资源就已经被这些冗长的“菜单”耗尽，且每次调用工具时，这些定义往往需要被重新处理，极大地降低了效率。

架构重叠与可靠性挑战

尽管MCP在2024年底发布时被誉为“AI生态系统的USB-C”，但在实际的日常开发中，其表现并未达到预期。除了上下文膨胀外，开发者还面临着严重的可靠性问题。MCP作为一个中间层，在复杂的生产环境中往往增加了调试的难度。此外，许多MCP提供的功能与现有的CLI工具或直接的API调用高度重叠。对于资深开发者而言，直接使用成熟的CLI或API往往比通过MCP这一层抽象更加高效且可控。

延迟加载：是治本还是治标？

针对上述问题，Claude Code近期推出了“带延迟加载的工具搜索”（Tool Search with Deferred Loading）功能。这一更新允许系统按需加载MCP工具模式，据称能减少85%以上的上下文占用。虽然这一举措在很大程度上解决了“上下文膨胀”的问题，但Quandri的报告强调，关于性能瓶颈、调试困难以及整体架构合理性的争论依然存在。MCP是否能真正成为行业标准，还是仅仅是一个过度设计的过渡方案，目前仍存疑问。

行业影响

该新闻反映了AI基础设施标准化过程中的现实挑战。虽然MCP试图通过统一协议简化LLM与外部数据的连接，但其带来的额外开销（Overhead）在高性能要求的工程实践中变得难以忽视。这促使行业重新思考：我们是需要一个万能的中间协议，还是应该优化现有的、更轻量级的集成方式？对于AI工具开发者而言，如何在功能丰富性与资源消耗之间取得平衡，将是下一阶段竞争的关键。

常见问题

问题 1：MCP的主要缺陷是什么？

根据Quandri的研究，MCP的主要问题在于它会大量消耗LLM的上下文窗口（Context Window），同时存在可靠性不足以及与现有开发工具（如CLI和API）功能重叠的情况。

问题 2：Claude Code的更新解决了MCP的哪些问题？

Claude Code通过“延迟加载”技术，将MCP工具定义的上下文占用降低了85%以上。这意味着工具定义不再一次性全部加载，而是根据需要动态调用，从而释放了更多的Token空间用于处理实际任务。

问题 3：为什么开发者将MCP比作“餐桌上的菜单”？

这是一个类比：当你坐在餐厅（LLM开始工作）时，如果桌子上铺满了10份巨大的菜单（MCP工具定义），你就没有空间放真正的食物（实际工作内容）了。这形象地说明了工具定义对上下文空间的挤占。