正文
尝试运行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的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”的问题则在于，复杂度“更上一层楼”，控制流程比前者更混乱，安全隐患更大。
此外，不得不提的就是安全问题。比如：
会话状态难管理，容易被劫持、中断或攻击；多入口扩大攻击面；实现复杂，掩盖恶意行为等等。
此外，MCP协议在授权上面也颇为混乱。如果你仔细查看，你就会发现MCP标准规定非常、荒唐——
