本文翻译自 MCP is Dead, Long Live the CLI，原载于 Hacker News。
我想做一个大胆的断言：MCP 已经在走向消亡。
我们可能还没完全意识到这一点，但迹象已经很明显了。OpenClaw 不支持它。Pi 也不支持它。而且这并非没有道理。
当 Anthropic 宣布 Model Context Protocol 时，整个行业都沸腾了。每家公司都争先恐后地发布 MCP 服务器，以证明自己是”AI first”。大量资源投入到新的端点、新的数据格式、新的授权机制——所有这些，只是为了让 LLM 能够与它们本来就能通信的服务进行通信。
说实话，我一直不太理解 MCP 的必要性。你知道 LLM 真正擅长什么吗？自己解决问题。给它们一个 CLI 和一些文档，它们就能飞起来。
我尝试了很久不去写这篇文章，但我现在确信：MCP 没有提供任何实际价值，我们不需要它。让我来解释一下。
LLM 不需要特殊协议
LLM 非常擅长使用命令行工具。它们在数百万个 man pages、Stack Overflow 回答和充满 shell 脚本的 GitHub 仓库上训练过。当我告诉 Claude 使用 gh pr view 123 时，它就能正常工作。
MCP 承诺提供一个更干净的接口，但在实践中，我发现我还是要写同样的文档：每个工具做什么、接受什么参数，以及更重要的是——什么时候用。LLM 根本不需要一个新协议。
CLI 对人类也很友好
当 Claude 用 Jira 做了一些出乎意料的事情时，我可以运行同样的 jira issue view 命令，看到它看到的确切内容。同样的输入，同样的输出，没有谜团。
而使用 MCP，工具只存在于 LLM 对话中。出问题了？现在你要去翻 JSON 传输日志，而不是直接运行命令。调试不应该需要协议解码器。
组合性
这是差距最大的地方。CLI 是可组合的。我可以通过 jq 管道、用 grep 链接、重定向到文件。这不仅方便，往往是唯一实用的方法。
考虑分析一个大型 Terraform plan：
terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
用 MCP 呢？你的选择是：把整个 plan 倾倒进上下文窗口（昂贵，而且常常不可能），或者在 MCP 服务器本身构建自定义过滤。无论哪种方式，你都在做更多的工作，却得到更差的结果。CLI 方法使用的是已经存在、文档完善、人类和 agent 都能理解的工具。
认证已经能用了
MCP 对认证的态度过于自以为是。为什么一个给 LLM 提供工具的协议需要关心认证？
CLI 工具不在乎。aws 使用 profiles 和 SSO。gh 使用 gh auth login。kubectl 使用 kubeconfig。这些都是久经考验的认证流程，无论是我在键盘前还是 Claude 在操作，工作方式都一样。当认证出问题时，我用一贯的方式修复：aws sso login、gh auth refresh。不需要专门针对 MCP 的故障排除。
没有活动部件
本地 MCP 服务器是进程。它们需要启动、保持运行、不能静默挂起。在 Claude Code 中，它们被作为子进程生成——这有时候管用，有时候不管用。
CLI 工具只是磁盘上的二进制文件。没有后台进程，没有状态要管理，没有初始化舞蹈。需要时它们就在那里，不需要时它们就隐身。
实际的痛苦
除了设计哲学，MCP 在日常使用中也有真正的摩擦：
初始化不稳定。 我已经数不清有多少次因为 MCP 服务器没有启动而重启 Claude Code。有时候重试能行，有时候我得清空状态从头开始。
无尽的重新认证。 使用多个 MCP 工具？那你有得忙了，每个都要认证。而带有 SSO 或长期凭证的 CLI 根本没有这个问题。认证一次就完事。
权限是全有或全无。 Claude Code 允许你按名称白名单 MCP 工具，但仅此而已。你不能限定只读操作或限制参数。而使用 CLI，我可以白名单 gh pr view 但要求批准 gh pr merge。这种粒度很重要。
那么 MCP 什么时候有意义？
我不是说 MCP 完全没用。如果一个工具真的没有 CLI 替代品，MCP 可能是正确的选择。我在日常工作中仍然使用很多 MCP 工具——当它们是唯一选择的时候。
我甚至可能承认，有一个标准化接口有一些价值，可能确实有一些 CLI 更合适的用例。
但对于绝大多数工作，CLI 更简单、更快调试、更可靠。
真正的教训
最好的工具是那些同时对人类和机器都有效的工具。CLI 经历了几十年的设计迭代。它们可组合、可调试，并且搭便车利用了已经存在的认证系统。
MCP 试图构建一个更好的抽象。结果发现我们已经有一个相当不错的了。
给构建者的呼吁
如果你是一家正在投资 MCP 服务器的公司，但你还没有官方 CLI，停下来重新思考你在做什么。
先发布一个好的 API，然后发布一个好的 CLI。Agent 们会自己搞定的。
总结
这篇文章提出了一个有趣的观点：与其花精力去适配 MCP，不如把现有的 CLI 工具做好。因为：
- LLM 天生会用 CLI —— 它们已经在海量命令行文档上训练过
- CLI 更易调试 —— 人和机器用同样的方式交互
- CLI 可组合 —— 管道、重定向这些 Unix 哲学仍然适用
- 认证已解决 —— 不需要在协议层面重新发明轮子
作者不是说 MCP 没用，而是说在大多数场景下，一个好的 CLI 可能比 MCP 服务器更有价值。这对我们开发者来说是个很好的提醒：在做 AI 集成之前，先把基础工具有效地暴露出来。