OpenClaw 已经爆火了好一阵子了。
大部分感兴趣的用户都已经尝试过「养龙虾」的操作，也有一部分人已经寻求彻底卸载，斩断与AI的孽缘。
这阵风有隐隐消退的趋势。但使用过 OpenClaw 的朋友们有没有发现，OpenClaw 不支持 MCP 协议。
模型上下文协议（Model Context Protocol，简称 MCP），在2024 年 11 月由 Anthropic 推出。推出后，MCP 在开发者和 AI 社区中迅速获得了广泛关注，被视为大模型通信和交互的标准协议。
但时间仅过了一年多，MCP 似乎已经销声匿迹了，就连 MCP 协议的「一周年纪念日」却在一片寂静中度过。从发布以来，MCP 的「builder 多于 user」、「旧瓶装新酒」的质疑始终存在。
而现在，MCP 似乎正在走向消亡。昨天，Perplexity 的联合创始人和 CTO Denis Yarats 在其公司内部表示，他们正在放弃 MCP，转而使用 API 和 CLI。
讽刺的是，这似乎是近期 MCP 声量最高的事件，引发了网友们的讨论。
网友们的想法都挺一致的，尤其是 Skills 逐渐占据了智能体应用的主场后，MCP 似乎早就应该消失了。
除了 Perplexity 以外，曾经对 MCP 集成的全面支持，甚至实现了 OAuth 和动态客户端注册的 AI 聊天工具 Duetchat ，在 v2 版本中，也彻底删除了 MCP 集成的功能。
就连 Y Combinator 总裁兼 CEO Garry Tan 也直言不讳：MCP sucks！
那么，MCP 到底有哪些问题，导致谁都不待见呢？
MCP 的天生缺陷
MCP 协议的模式是：定义一组工具（带有 Schema 的函数），将其注入 Agent 的上下文，然后让 Agent 调用它们。
这种模式可行，但难以为继。核心问题在于线性上下文成本。
你添加的每一个 MCP 工具，包括它的名称、描述、参数 Schema 和示例，都会占用 Agent 的上下文窗口。如果你连接 10 个服务，每个服务有 5 个工具，那么在 Agent 开始执行任何任务之前，你就已经烧掉了数千个 Token。
所以在使用MCP协议之前，我们只能选择：
• 预先加载所有内容：接受实际任务性能的下降（推理空间、对话历史和工作记忆被挤占）。
• 限制集成数量：接受你的 Agent 只能与少数几个服务通信的现实。
• 构建动态工具加载：接受工具选择中间件带来的延迟和复杂性。
这些都不是理想方案。上下文窗口是 Agent 拥有的最宝贵的「房地产」，使用 MCP 协议是一种极大的浪费。