关于 MCP 为何未能成功及下一步的思考

MCP 发布时，最好的模型是 Sonnet 3.5 和 GPT 4o
当时我们对如何正确使用这些工具还所知甚少，仍然非常担心模型访问工具、上下文膨胀等问题
结果我们得到了一堆基本无用的 MCP 服务器，例如 Vercel 的 MCP 服务器在发布时只有大约 7 个工具，功能非常有限，而且由于安全方面的过度谨慎，公司限制谁能调用它

大约二月份 Claude Code 发布，人们意识到“直接给 agent 一个 bash 工具就行了”。给 agent 一个 bash 工具，它就能串联命令、过滤输出、动态安装 CLI

人们意识到工具越少，模型表现越好——虽然这其实并不正确。想想 GitHub CLI 包含多少“工具”，成千上万，尤其是模型可以通过 gh api 直接调用 API

比较一下使用 MCP 和使用 CLI 的体验：你可以直接告诉 agent “嘿，安装这个 CLI”，然后马上开始使用。而大多数支持 MCP 的框架要求你完全重启客户端才能调用它，这对用户来说是巨大的摩擦。Bash 得益于 37 年来在优秀原语上的惊人发展，而 MCP 的实现大多是在一个月内 vibe coded 出来的

现在 MCP 处于一种尴尬的状态。再回到 Vercel 的例子：他们的 CLI 已经推出了 vercel api，让你的 agent 能够调用完整的 API。这很好，然而他们的 MCP 目前只有 20 个工具，而且大部分是只读的。同时，只有大约 16 个被允许的客户端可以集成它，这在一款被人们在危险模式下跳过权限运行的 CLI 面前毫无意义

那么我们应该拥抱 CLI 吗？我对此有相当大的保留意见。大多数 CLI 实际上只是对 API 的简单包装。通过设计良好的 CLI 认证流程而非 API 认证流程，你引入了大量的状态性问题。一个只用来读邮件的 agent 不应该为了运行 Google Workspace CLI 而启动整个容器，而惰性工具加载或代码模式就可以做到

CLI 的另一个问题是不理解其操作空间。你可以轻松地将 MCP 转换为 CLI，但不能以同样的方式将 CLI 转换为 MCP。CLI 也没有 MCP 或 OpenAPI 规范中关于哪些操作具有破坏性的注释，虽然 LLM 已经足够好，这一点已经不是那么重要了

目前围绕 MCP 的一些迷思：

工具太多会导致上下文膨胀

对于实现糟糕的客户端来说确实如此，但大多数客户端现在已经实现了惰性加载，模型可以动态发现工具。

协议支持很差

我后面会再写一篇文章讨论这个问题，但你可以通过创造性的方式绕过大部分不受支持的 MCP 规范。这是一个先有鸡还是先有蛋的问题。

认证体验糟糕

某种程度上是的，有些客户端支持较差并需要改进，但在 Claude Code 中我从未被登出过，体验很好。

我们应该直接调用 API

是的，我同意！我创办 Executor.sh 这家公司，部分原因正是基于这一点。我们的框架不应该关心我们试图集成什么。MCP、CLI、API、GraphQL 等都应该被支持，agent 可以调用所有这些。

这正是 Executor 的优美之处——它不关心你带来什么，只管能否将其纳入工具目录。

我们必须承诺使用 MCP 吗？我把这个问题留给正在构建框架的团队（如 Codex、Claude Code、OpenCode 等）。如果你们能够一起提出一个规范，并获得像 MCP 这样强大的采用（基本上每个客户端现在都支持它），那就太好了。但从我的角度看，MCP 的广泛采用已经解决了最困难的部分，现在我们只需要继续推进使其变得更好。

我个人对 MCP 的未来非常兴奋。无状态化提取很棒，更多客户端采用代码模式也非常好。MCP 应用在未来六个月内具有解锁新交互模式的巨大潜力。通过 MCP 进行技能加载，对于提供远程源及其调用方式的上下文也极有帮助。

我期望最终的世界是：所有公司都为其 MCP 服务器和 OpenAPI 规范支持 CIMD OAuth。OpenAPI 规范用于原始数据访问和批量处理，而 MCP 则提供更精心策划的体验，可能包含一个类似 Vercel 和 GitHub CLI 感觉的 api 工具。

最后几点想法：

• 插件很糟糕，应该避免，它们会造成大量的锁定和可移植性问题，导致封闭的生态系统
• 这项技术非常新，做批评者比做玩家容易得多，MCP 总体在推动采用方面做得非常出色
• 大多数 MCP 服务器本可以只是对 API 的直接调用，就像大多数 CLI 本可以只是对 API 的直接调用一样