本文作者Eric Holmes认为MCP（Model Context Protocol）正在走向衰落，尽管它曾被业界热捧。他认为CLI（命令行工具）才是真正对人类和AI agent都有价值的工具，MCP虽然一时兴起，但存在诸多实际问题。作者主张"对人类和机器都友好的工具才是最好的工具"，CLI经过数十年的迭代设计，更具可组合性、可调试性，且能复用已有的认证系统。

文章结构

1. MCP的兴衰

Anthropic宣布MCP后，整个行业为之疯狂
每家公司都争相推出MCP服务器作为"AI优先"的证明
大量资源投入到新端点、新授权方案
但OpenClaw、Pi等平台不支持MCP

2. LLMs不需要特殊协议

LLMs擅长使用命令行工具
训练数据中包含大量man pages、Stack Overflow答案、shell脚本
给LLM一个CLI和一些文档，它就能工作
MCP并未简化这个过程，仍需要写文档说明每个工具的用途和参数

3. CLI也是为人类设计的

当Claude在Jira上操作异常时，你可以直接运行jira issue view命令查看
相同的输入，相同的输出，没有神秘感
MCP的工具只存在于LLM对话中，出了问题要查看JSON传输日志
调试不应该需要协议解码器

4. 可组合性

CLI可以管道传输、grep过滤、重定向文件

分析大型Terraform plan：

terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'

MCP的选项：要么把整个plan塞入上下文窗口（昂贵且往往不可能），要么在MCP服务器中构建自定义过滤

5. 认证已不是问题

MCP对认证过度主观
CLI工具不关心认证方式：aws用profiles和SSO，gh用gh auth login，kubectl用kubeconfig
这些都是经过实战检验的认证流程
认证断开时，用熟悉的方式修复：aws sso login、gh auth refresh

6. 没有移动部件

本地MCP服务器是进程，需要启动、保持运行、不能静默挂起
CLI工具只是磁盘上的二进制文件
无后台进程、无状态管理、无初始化流程

7. 实际痛点

初始化不稳定：经常需要重启Claude Code因为MCP服务器没启动
重新认证无休止：使用多个MCP工具？每个都要认证
权限全有或全无：只能按名称允许列表MCP工具，无法限制到只读操作或参数

8. 何时MCP有意义

某些工具确实没有CLI等价物时
有标准化接口的价值

思考

作者对MCP的批评有一定道理，但我有一些存疑：

作者是否低估了MCP在复杂工作流编排方面的潜力？
CLI方案在处理需要状态维护的多步骤任务时，是否真的比MCP更优？
对于不熟悉命令行的用户，MCP的抽象是否更有价值？

MCP已死，CLI永存（读书笔记）