MCP 这玩意儿，是没戏了。openclaw 这个项目让人彻底看清了，API 和命令行（CLI）才是最终的赢家。
为什么这么说？因为 MCP 有个致命的硬伤——太占内存（上下文）了！
你想啊，每当你连上一个 MCP 服务器，它都要把所有的工具定义（名字、描述、参数格式）一股脑儿塞进模型的脑子里。你连 10 个服务器，每个有 5 个工具，好家伙，还没开始干活呢，模型一半的脑子已经被这 50 个工具说明书占满了！
这种“上下文臃肿”绝对不是好事，不管是从运行速度还是从烧钱（算力成本）的角度看，这都是不可持续的。
我猜这也是为什么 @steipete 在搞 @openclaw 的时候，压根就没理这个 MCP 的原因。
其实你根本不需要那么复杂的东西，你只需要两样神器：
1. “执行”工具（exec）：能运行命令就行。
2. 按需技能（on-demand skills）：需要啥功能再调用啥。
这才是王道啊！
这简直让那些古老的、强大的命令行工具（比如 curl, sed, awk, grep）迎来了第二春！这些东西当年可是大神（greybeards）们的标配，但后来被各种花里胡哨的现代框架给埋没了，搞得现在的小年轻都不会用了。
现在好了，有了最强的 AI 智能体openclaw当司机，咱们普通人都能用上这些神器了。每个创业者都能拥有自己的一支“大神军团”来打工。
至于 MCP，想要让大家抛弃现有的习惯去适应它，这股“惯性”太大了。相比之下，@openclaw 带来的“API + CLI + 技能”这套组合拳势头太猛，MCP 根本挡不住。
我知道有人要替 MCP 辩护，无非就是那几套说辞，我来一一回怼：
* 辩解一：“MCP 能提供类型化结构和验证啊！”
* 回怼： 一个写得好的命令行文档（CLI）也能做到验证，别拿这个当挡箭牌。
* 辩解二：“MCP 有明确的权限控制！”
* 回怼： 我用一个带白名单的沙箱（sandbox）执行命令，一样安全，甚至更安全。
* 辩解三：“MCP 是个标准啊！”
* 回怼： 一个扩展性极差（指上下文爆炸）的标准，哪怕它是国际标准，也是个烂标准。
最后再补一刀：我听说很多 MCP 服务器其实干的都是“套娃”的活儿，就是把现有的 API 包了一层壳。这种多余且不必要的中间商，简直就是危险信号（red flag）。
所以，别折腾了，咱们还是散了吧。赶紧把精力都撤回来，专心搞 CLI 工具、API 和配套的技能才是正道！
总结一下核心观点：
MCP 属于“重装上阵”，太笨重；而 CLI 属于“轻装上阵”，更灵活。在 AI 时代，让模型去操控那些经典的命令行工具，比给它塞满各种工具说明书要高效得多。