今天 HackerNews 上有一篇很有趣的文章《MCP 已死，CLI 永生》。 它断言 MCP 已经在走向衰亡。理由是：大模型并不需要特殊的协议。最好的工具总是既能为人所用，又能被机器高效处理的。而 CLI 就是那一个很好的工具。如果现在的轮子就很好用，我们并不需要再次发明轮子。
下面是全文翻译：原文地址
MCP 已死，CLI 万岁
我要做一个大胆的判断：MCP 已经在走向衰亡。我们也许还没有完全意识到，但迹象已经很明显了。OpenClaw 不支持它。Pi 不支持它。而且理由非常充分。
当 Anthropic 发布 MCP（Model Context Protocol）时，整个行业都沸腾了。每家公司都争先恐后地上线 MCP 服务器，以证明自己是“AI First”。大量资源被投入到新的端点、新的传输格式、新的授权方案里，只为让 LLM 能与它们本来就能对话的服务通信。
我承认，我一直没有完全理解它的必要性。你知道 LLM 真正擅长什么吗？自己把事情搞明白。给它们一个 CLI 和文档，它们就能一路狂奔。
我一直想避免写这篇文章，但我现在确信，MCP 在现实世界里并没有带来真正收益，而且没有它我们会更好。让我解释一下。
LLM 并不需要特殊协议
LLM 非常擅长使用命令行工具。它们接受过数以百万计的用户手册、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 方法用的是已经存在、文档完善、且人和代理都懂的工具。
身份认证本来就能正常工作
MCP 在身份认证上过于“有主见”。而一个为 LLM 提供工具的协议，为什么要操心身份认证？
CLI 工具就从来不会在意这些。aws 用 profiles 和 SSO。gh 用 gh auth login。kubectl 用 kubeconfig。这些都是经过实战检验的认证流程，不论我自己在键盘前操作，还是用 Claude 在驱动，都是同一套。当认证出问题时，我照常处理：aws sso login、gh auth refresh。不需要任何 MCP 专属排障。
No moving parts
本地 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）有几十年的设计迭代。它们可组合、可调试，并且可以与现有的身份验证系统无缝集成。
MCP 试图构建一个更好的抽象。结果发现，我们其实早就有一个很不错的抽象了。
给开发者的一些呼吁
如果你是一家正在投入 MCP 服务器、却没有官方 CLI 的公司，先停下来重新思考一下你的计划。先推出优秀的 API，再推出优秀的 CLI。用户自己会把它们用起来。
