MCP 很火，但你可能根本不需要它
MCP 是 2025 年最火的 AI 协议。但有人说它已经死了。
这话听起来夸张，但 Eric Holmes 最近写了篇文章，标题就叫《MCP is dead. Long live the CLI》。原文链接
他的核心观点：MCP 不是 CLI 的替代品，大多数场景下 CLI 更好用。
我觉得他说得有道理。
MCP 是什么？
先快速科普一下。MCP（Model Context Protocol）是 Anthropic 推出的协议，让 LLM 能调用外部工具。
听起来很美好：统一接口、标准化调用、AI 原生。
但问题来了：LLM 真的需要一个专门的协议吗？
CLI 能做什么 MCP 做不到的？
1. LLM 本来就会用 CLI
Claude 读过几百万份 man page、Stack Overflow 回答、GitHub 上的 shell 脚本。你让它跑 gh pr view 123，它直接就能用。
MCP 承诺更干净的接口，但实际上你还是得写文档：这个工具干嘛的、参数是什么、什么时候用。LLM 不需要新协议，它需要好文档。
2. 出问题能直接调试
Claude 用 Jira 出了问题？你跑一遍 jira issue view 就知道它看到了什么。同样的输入，同样的输出，没有黑盒。
MCP 呢？工具只存在于 LLM 对话里。出问题你得翻 JSON 传输日志。调试不应该需要协议解码器。
3. 可以组合
这是差距最大的地方。CLI 能组合。管道、grep、jq、重定向，这不只是方便，很多时候是唯一可行的方案。
比如分析一个大型 Terraform plan：
terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
用 MCP？要么把整个 plan 塞进上下文（贵，而且经常塞不下），要么在 MCP server 里写自定义过滤。两种方案都比 CLI 麻烦。
4. 认证已经解决了
MCP 对认证有自己的一套想法。但为什么一个给 LLM 用的协议要管认证？
CLI 工具不管这些。aws 用 profile 和 SSO，gh 用 gh auth login，kubectl 用 kubeconfig。这些认证流程经过实战检验，人用和 Agent 用都一样。
认证出问题？aws sso login、gh auth refresh，不需要 MCP 专属的排查流程。
5. 没有运行时依赖
本地 MCP server 是进程。要启动、要保持运行、不能静默挂掉。在 Claude Code 里，它们作为子进程启动，大部分时候能用，但有时候就是不行。
CLI 工具就是磁盘上的二进制文件。没有后台进程，没有状态管理，没有初始化流程。需要的时候在，不需要的时候不碍事。
MCP 的实际痛点
Eric 列了几个日常使用的问题：
初始化不稳定。他数不清重启了多少次 Claude Code，就因为 MCP server 没起来。有时候重试能好，有时候得清状态重来。
认证没完没了。用多个 MCP 工具？每个都要认证一遍。CLI 配合 SSO 或长期凭证就没这问题，认证一次搞定。
权限太粗。Claude Code 能按名字白名单 MCP 工具，但就这样了。你没法限制只读操作或特定参数。CLI 可以：白名单 gh pr view，但 gh pr merge 要审批。这种粒度很重要。
什么时候 MCP 有意义？
Eric 也承认 MCP 不是完全没用。如果一个工具真的没有 CLI 替代品，MCP 可能是对的选择。
标准化接口也有价值，某些场景下确实比 CLI 更合适。
但对大多数工作来说，CLI 更简单、更好调试、更可靠。
决策树
下次你在纠结用 MCP 还是 CLI，问自己三个问题：
- 这个工具有 CLI 吗？ 有就用 CLI。
- 需要组合多个工具吗？ 需要就用 CLI，管道和 jq 是你的朋友。
- 调试方便吗？ CLI 能直接跑，MCP 得翻日志。
只有当三个问题的答案都指向 MCP 时，再考虑用它。
给开发者的建议
Eric 最后说了一句话，我觉得很中肯：
如果你是一家公司，正在投资 MCP server 但没有官方 CLI，停下来重新想想。先发布好的 API，再发布好的 CLI。Agent 会自己搞定的。
最好的工具是人和机器都能用的。CLI 经过几十年的设计迭代，可组合、可调试、复用现有的认证系统。
MCP 试图构建更好的抽象。但我们其实已经有一个挺好的了。
来源：
- MCP is dead. Long live the CLI - Eric Holmes
- HN 讨论 - 122↑ 96 评论