摘要：这篇文章的作者Rasmus Holm，是一家创业公司CTO，三个星期前，他想在自己的实际环境中亲自上手实操一番MCP，结果大失所望。
现在的MCP乃至大模型开发圈，就像尿了裤子！一开始热乎乎的，然后就开始难受了！
近日，一篇有关MCP深度批判的博客文章《A Critical Look at MCP》在网络上走红。
MCP的热度暴涨十足，它甚至有望成为一种席卷全球的生态级别的协议，是一件有目共睹的事情。
这篇文章的作者Rasmus Holm，是一家创业公司CTO，三个星期前，他想在自己的实际环境中亲自上手实操一番MCP，结果大失所望。
Rasmus在这篇文章中非常细节，甚至可以说把MCP的内裤都扒光了一遍，不管是协议层还是传输层都把文档中许多“雷点”都筛了出来。
Rasmus在文中难掩愤怒：自己本意并非想攻击MCP协议，但实在是忍无可忍，不吐不快！
“我真心希望这只是我技术不到位的问题，并希望自己是误解了什么。”
Rasmus在摘要中首先痛斥了自己所看到的大模型圈内一众普遍现象：低质量的开发文档——
“IBM 最近发布了他们自己的 MCP‘正交标准’，称为代理通信协议 (ACP)，紧接着谷歌宣布了agent2Agent (A2A)。MCP 服务器和客户端每天都在构建和发布……
然而，各大厂商花几十亿美元训练和调教模型，结果却让实习生写文档，提供粗糙的 SDK，几乎没有实现指导。”
“让我震惊的是，整个LLM生态工程实践的成熟度非常糟糕！”
可让Rasmus失望的是，即便是期望值如此之高的MCP，居然也没有避开这样的“恶习”，出现了很多奇怪的设计决策、糟糕的文档，以及更糟的协议规范。
例如，打开MCP的官方文档modelcontextprotocol.io，“你会发现文档写得一团糟”，而且Rasmus顺带怼了几乎所有 LLM 厂商，“这些厂商似乎在比谁写得更让人迷惑看不懂”。
具体比如，规范完全忽略了协议中的重要细节，也没有任何会话流程的例子。整站的重点都不是帮你了解协议，而是引导你去用他们的 SDK 教程。
此外，所有示例服务器都用 Python 或 JavaScript 编写，这两种语言都是部署到别人电脑上的噩梦。所以示例都提供了 Docker 镜像，开发者心里也是有数的。
关于这一点，Rasmus认为MCP团队没有注意到在编写本地MCP服务器时，人们未必会首选Python语言，比如作者本人就选择了用Go语言来构建，任何尝试运行HuggingFace项目的人都该能够深有体会。
相信大家都知道，教程上Python的pip安装虽然写的简单，但实际对于非主攻Python的人而言，简直是一场噩梦。
想一想，你上一次运行 pip install 没遇到依赖地狱是什么时候？作者如是说：你要是真打算在本地跑 MCP，不是该选 Rust、Go，或者至少 Java、C# 这类更通用的语言吗？
再比如，在一开始Rasmus实现HTTP协议时，就感到必须反向工程整个传输机制。因为文档里完全没说清楚 SSE 的细节，甚至连MCP自己的工具都没支持“Streamable HTTP”，一个典型的例子是npx @modelcontextprotocol/inspector@latest，如果你一不留神，很可能会因为拉错了版本导致失败。
还有，架构理清了还不算完。因为不管是服务器还是客户端，你都会实现MCP都是个巨大的工程。因为 SSE / Streamable HTTP 都试图模拟套接字行为，却又不是套接字等等，诸如这些问题简直把人逼疯。
MCP号称是AI时代的标准化接口，如同可以连接各种工具的“USB-C”。然而Rasmus经过一番实践，从协议层到传输层，都狠狠给MCP了一记耳光。
协议层方面，Rasmus指出，MCP其实是一个基于JSON-RPC的协议，定义了一些预设方法和端点，供 LLM 使用。“虽然这篇文章不是专门批评协议本身，但它也存在不少问题。”
不过Rasmus更想吐槽的问题还是在传输层。
这个“可在多种传输协议上运行的新协议”，听起来非常刺激，然而Rasmus经过一番实操之后实锤了MCP的的“言过其实”——
MCP当前建议的HTTP传输方式，不管是SSE + HTTP 还是所谓的“Streamable HTTP”，都应该被彻底抛弃，不如改用类似stdio的东西，比如Websocket。
具体来讲，Rasmus指出，SSE 模式上出现的问题集中在文档缺失、实现复杂、服务端需要绑定多个连接。典型的错误就是，一个请求写到 A 服务器，SSE 却连在 B 服务器上？必须加消息队列。
而“Streamable HTTP”的问题则在于，复杂度“更上一层楼”，控制流程比前者更混乱，安全隐患更大。
这就会导致相对应的API设计堪比地狱级难度。
此外，不得不提的就是安全问题。比如：会话状态难管理，容易被劫持、中断或攻击；多入口扩大攻击面；实现复杂，掩盖恶意行为等等。
此外，MCP协议在授权上面也颇为混乱。如果你仔细查看，你就会发现MCP标准规定非常、荒唐——
STDIO：从环境变量取凭证，随便你HTTP：必须实现 OAuth2为啥 HTTP 就要强制走 OAuth2，STDIO 却可以用 API Key？什么道理呢？不知道。主打一个随意。
这里具体展开看一下。据官方文档显示，MCP 目前支持的主要传输方式有两种，也可以说是三种：标准输入输出（stdio）、HTTP + SSE，还有一种则是所谓的“Streamable HTTP”。
然而这三个协议具体真实的支持程度如何？作者一条条都过了一遍，给出了自己的评价：stdio是目前最靠谱的传输方式！
并进一步解释了原因：
就像很多 2005 年之后的应用一样，MCP 声称是“本地优先”的协议。这一点从传输协议的设计上就能看出 —— 它明显是为本地开发者工具准备的，比如本地 IDE，或者更现实点说，是 Cursor 和 Windsurf。
然而，靠谱并不意味着没问题。“通过stdio意味着启动一个本地MCP Server，把服务器的stdout/stdin接到客户端上，然后开始发送JSON，同时用stderr做日志。这种方式违背了 Unix/Linux 使用这些流的初衷——它们本是单向的，但MCP变成了双向通信。”
尽管有批评之处，但作者对这种做法表示理解，这样做是为了更简单、容易推理、跨平台无需额外配置，而不需要管socket。
而接下来的两个远程传输协议的方式，Rasmus则完全表示不解！HTTP 传输方式就很混乱了。这是两个版本的“错误实现”！
使用 Server-Sent Events (SSE) 来流式传输数据；“Streamable HTTP” —— 这是一个杜撰的词，用 REST 方式包裹 SSE，但增加了大量复杂度和边缘情况。总结来说，MCP团队不想用 WebSocket，于是“造了一个 WebSocket”，然后美其名曰“Streamable HTTP”，让它听起来像是被广泛接受的做法。
作者还深扒MCP团队在Github上PR #206 中试图解释为何不用 WebSocket，但论证非常牵强。评论区也有人表达了相同的不满。
“我试图用 Go 实现一个 MCP Server —— 结果简直就是精神摧残。”
Rasmus的心情可以用“崩溃”二字来形容。他甚至毫不客气地把MCP甚至整个模型圈的这种现象比喻为“在尿裤子” —— 现在热乎乎的，但之后会很难受。
STDIO 模式HTTP 模式环境变量HTTP Header流/双向通信WebSocket尤其关于最后一点，Rasmus解释到，因为WebSocket 完全可以做同样的事情，而且更合理，支持双向、去中心化的会话状态管理，避免各种边角问题。
按照MCP官方所强调的——
客户端和服务器可实现任何自定义传输协议，MCP 协议是传输无关的，只要支持双向消息交换即可。
—— modelcontextprotocol.io
我们应该为最常见的使用场景做优化，而不是为边角情况做妥协。
IBM 和 Google 推出的 ACP 与 A2A 实际上是 MCP 的变体。MCP 是“让 LLM 使用 API”，ACP/A2A 则是“让 LLM 使用 Agent”。
A2A 的很多功能其实 MCP 也能做。IBM 甚至表示：
Agent 可以被视为 MCP 的资源，也可以作为工具调用
—— IBM / agentcommunicationprotocol.dev
Rasmus认为，ACP 更像是 IBM 推广其 BeeAI agent 构建工具的手段。
整篇文章，Rasmus可谓是直言直语，在一篇叫好声中，点出了MCP协议目前存在的大量问题：文档规范成熟度不够、协议层面的实现不合理、本地实现工程难度大等等。
正是因为实际所感，这一篇激情吐槽在Hackernews上引起了网友的共鸣，1天之内迅速引起了多达317条的评论。
很多网友就像被打开了“话闸”一样，纷纷表示：现在大模型开发相关的文档写得很差！
更有网友曝料：MCP spec [0] 里到处都是 LLM 的痕迹。他们几乎都在用 LLM 来写文档，但这仍然是个很糟糕的主意。
甚至这位网友打趣地说道：事实上，滥用大模型来构建规范比滥用它们来避免编写优秀的文档要糟糕得多，因为对于规范和 RFC 来说，编写规范的过程才是关键所在。
为什么这么确定？
这位网友解释道：最终，MCP 规范是 LLM 的产物的最大标志不是它有些不连贯，或者它完全由项目符号列表组成，或者它具有那种独特的平淡风格：而是它显示出相对于我们对主要规范的期望而言，它几乎没有经过人类思考。
因为一般而言，一份高可读的合格的输出文档，通常还要努力找出你当前思维的所有缺陷、不足和不完整之处。你需要批判性地阅读规范，识别边缘情况，并不断修改规范，直到它能够解答规范设计人员和相关社区的所有疑问。
当然，还有不少网友相信MCP团队的成员，相信他们会快速跟进，修改文章中所提到问题。因为Anthropic中确实有一些很敏锐的人才！
此外，也有海外的网友提到了DeepSeek的开源文档同样也有不少让人读不懂的地方。主要还是因为内容翻译方面太过“Chinglish”的原因。
不过，话说回MCP，有网友表示，对于更多MCP服务器构建的大众程序员而言，现在还是太难了，只需要有人会编写一个MCP适配器，让Claude使用OpenAPI即可，因为这样大家就可以忘掉MCP的存在了！
不得不说，这也是一枚典型的“等等党”了！
最后，MCP如火如荼，但小编了解到一些业内人士仍在持怀疑或观望的态度，一方面是因为Anthropic的生态能否大成，突围OpenAI尚未可知，另一方面则在于MCP协议目前尚存在不少局限性，比如本文提到的主打本地而不能远程、安全问题等等。
那么，问题来了，咱们如何看待Rasmus有关MCP的无情痛批呢？
https://news.ycombinator.com/item?id=43945993
来源：51CTO一点号
