文章认为MCP（模型上下文协议）正在消亡，因为它并未带来实际价值。作者指出大型语言模型（LLM）本身就擅长使用命令行工具（CLI），无需专门协议。许多公司盲目追捧MCP只是跟风，而实际上提供文档和CLI就能让LLM高效工作。作者主张放弃MCP，回归更简单直接的CLI交互方式。

标题：MCP已死，CLI长存

我要提出一个大胆的论断：MCP协议正在走向消亡。虽然我们可能尚未完全意识到，但迹象已十分明显。OpenClaw不支持它，Pi也不支持它——这并非没有道理。

当Anthropic公司推出模型上下文协议（MCP）时，整个行业陷入了疯狂。每家企业都争相推出MCP服务器，以此证明自己是"AI优先"的践行者。大量资源被投入到新的端点、新的传输格式、新的授权方案上，而这一切只是为了让人工智能模型能够与其本就具备交互能力的服务对话。

必须承认，我始终未能理解这种协议的必要性。你知道大型语言模型最擅长什么吗？自主解决问题。给它们一个命令行工具和相关文档，它们就能大显身手。

经过长期观察，我确信MCP并未带来实质性的益处，我们完全可以摆脱它。以下是我的分析：

1. 模型不需要特殊协议 大型语言模型天生擅长使用命令行工具。它们已经学习了数百万页手册、Stack Overflow解答和充满shell脚本的GitHub仓库。当我让Claude执行gh pr view 123时，它可以直接运行。

2. CLI的双重优势 当Claude与Jira的交互出现异常时，我只需运行相同的jira issue view命令就能复现场景。输入相同，输出相同，问题一目了然。而使用MCP时，调试需要分析JSON传输日志而非直接执行命令。

3. 强大的组合性 命令行工具具有天然的管道组合能力。例如分析Terraform方案时： terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length' 而MCP方案要么需要加载整个方案（成本高昂），要么需要在服务器端实现定制过滤逻辑。

4. 成熟的认证体系 CLI工具采用各自久经考验的认证方案：aws使用配置文件和SSO，gh通过gh auth login认证，kubectl使用kubeconfig。这些方案无论对人工操作还是AI代理都同样有效。

5. 稳定性优势 MCP服务器作为进程运行，存在启动失败或挂起的风险。而CLI工具只是磁盘上的可执行文件，无需管理后台进程或初始化流程。

实际使用中的痛点包括： - 初始化过程不稳定 - 重复认证问题 - 权限控制过于粗放

虽然MCP在某些特殊场景仍有价值（如没有CLI替代方案时），但对于绝大多数工作场景，CLI具有更简单、更易调试、更可靠的显著优势。

核心启示在于：最好的工具应该同时服务于人类和机器。命令行工具经过数十年迭代，具备组合性、可调试性，并能复用现有认证体系。我们曾经试图构建更好的抽象方案，但最终发现早已拥有足够优秀的解决方案。

最后呼吁开发者：如果您的公司正在投资MCP服务器却没有官方CLI，请重新审视这个决定。优先提供优秀的API，然后开发完善的CLI工具——人工智能代理自会找到使用之道。

以下是评论内容的总结：

支持MCP的观点

1. 适合非技术用户：MCP为普通用户提供了简单易用的接口，无需技术背景即可操作。

   • "MCP is point-and-click for them. MCP is far from dead, at least outside of tech circles."（p_ing）
   • "For the other 99% of the population, MCP offers security guardrails and simple consistent auth."（sebast_bake）

2. 安全性与标准化：MCP提供了更好的安全控制和标准化认证流程。

   • "MCP is a great unit of encapsulation... it makes securing agent capabilities really easy."（CuriouslyC）
   • "MCP offers security guardrails and simple consistent auth."（sebast_bake）

3. 企业应用广泛：数据显示MCP在企业中的采用率快速增长。

   • "Number of companies with a MCP server grew 242% in the last 6 months."（AznHisoka）

支持CLI的观点

1. 灵活性与效率：CLI更适合技术用户，操作更灵活且响应更快。

   • "CLIs are still slightly more token efficient but overall the simplicity and the power of the scheme is a huge win."（CuriouslyC）
   • "CLIs also feel 'snappier' than MCPs. MCPs often have latency."（wenc）

2. 本地环境集成：CLI能更好地利用本地工具和环境。

   • "CLI tools on the other hand are like precision instruments... they have access to your local environment."（wenc）
   • "why would you spend time setting up and installing an mcp server when u can give it one man page"（Nevin1901）

3. 适合技术场景：CLI在技术密集型任务中表现更优。

   • "For personnal agents like claude code, clis are awesome."（brumar）
   • "CLI is only used in products... that are targeting technically competent users."（sebast_bake）

中立观点

1. 两者各有适用场景：根据具体需求选择合适工具。

   • "MCP for anything stateful... and CLI for stateless operations."（jackfranklyn）
   • "Why choose if you can have both?"（mavam）

2. 未来可能出现更好的方案：当前争论可能像过去的REST vs GraphQL，未来可能有新方案取代两者。

   • "Honestly the whole debate feels like REST vs GraphQL circa 2017."（jackfranklyn）

3. 协议设计的重要性：关键在于如何高效传递工具的使用信息。

   • "what matters is not MCP or CLI but 'to achieve X must use F'."（drdaeman）

关键引用

• 支持MCP：

  • "MCP is a great unit of encapsulation."（CuriouslyC）
  • "MCP offers security guardrails and simple consistent auth."（sebast_bake）

• 支持CLI：

  • "CLIs are still slightly more token efficient."（CuriouslyC）
  • "CLIs also feel 'snappier' than MCPs."（wenc）

• 中立观点：

  • "MCP for anything stateful... and CLI for stateless operations."（jackfranklyn）
  • "Why choose if you can have both?"（mavam）