痛斥！現在的MCP，就像尿褲子！創業CTO試用后怒氣值飆升，開懟整個大模型圈怪象：開發文檔用大模型寫的！ 原創
作者 | 云昭
出品 | 51CTO技術棧（微信號：blog51cto）
現在的MCP乃至大模型開發圈，就像尿了褲子！一開始熱乎乎的，然后就開始難受了！
近日，一篇有關MCP深度批判的博客文章《A Critical Look at MCP》在網絡上走紅。
圖像
MCP的熱度暴漲十足，它甚至有望成為一種席卷全球的生態級別的協議，是一件有目共睹的事情。
這篇文章的作者Rasmus Holm，是一家創業公司CTO，三個星期前，他想在自己的實際環境中親自上手實操一番MCP，結果大失所望。
Rasmus在這篇文章中非常細節，甚至可以說把MCP的內褲都扒光了一遍，不管是協議層還是傳輸層都把文檔中許多“雷點”都篩了出來。
Rasmus在文中難掩憤怒：自己本意并非想攻擊MCP協議，但實在是忍無可忍，不吐不快！
“我真心希望這只是我技術不到位的問題，并希望自己是誤解了什么。”
1.低質的MCP文檔，像大模型生成的一樣！
Rasmus在摘要中首先痛斥了自己所看到的大模型圈內一眾普遍現象：低質量的開發文檔——
“IBM 最近發布了他們自己的 MCP‘正交標準’，稱為代理通信協議 (ACP)，緊接著谷歌宣布了Agent2Agent (A2A)。MCP 服務器和客戶端每天都在構建和發布……
然而，各大廠商花幾十億美元訓練和調教模型，結果卻讓實習生寫文檔，提供粗糙的 SDK，幾乎沒有實現指導?！?/p>
“讓我震驚的是，整個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 都試圖模擬套接字行為，卻又不是套接字等等，諸如這些問題簡直把人逼瘋。
2.制造了太多地獄級問題MCP的HTTP傳輸方式應被徹底拋棄！
MCP號稱是AI時代的標準化接口，如同可以連接各種工具的“USB-C”。然而Rasmus經過一番實踐，從協議層到傳輸層，都狠狠給MCP了一記耳光。
協議層方面，Rasmus指出，MCP其實是一個基于JSON-RPC的協議，定義了一些預設方法和端點，供 LLM 使用?！半m然這篇文章不是專門批評協議本身，但它也存在不少問題。”
不過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？什么道理呢？不知道。主打一個隨意。
3.三個協議，只有“本地”相對靠譜！其余兩個都是錯誤實現
這里具體展開看一下。據官方文檔顯示，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，但論證非常牽強。評論區也有人表達了相同的不滿。
4.整個大模型開發生態像是在尿褲子
“我試圖用 Go 實現一個 MCP Server —— 結果簡直就是精神摧殘?！?/p>
Rasmus的心情可以用“崩潰”二字來形容。他甚至毫不客氣地把MCP甚至整個模型圈的這種現象比喻為“在尿褲子” —— 現在熱乎乎的，但之后會很難受。
Ras并對MCP協議給出了三點統一行為模式的建議：
- 協議只有一個：JSON-RPC
- 首選傳輸方式：Stdio
- HTTP 模式下，該用 WebSocket 模擬 stdio，而不是玩花的
STDIO 模式 | HTTP 模式 |
環境變量 | HTTP Header |
流/雙向通信 | WebSocket |
尤其關于最后一點，Rasmus解釋到，因為WebSocket 完全可以做同樣的事情，而且更合理，支持雙向、去中心化的會話狀態管理，避免各種邊角問題。
按照MCP官方所強調的——
客戶端和服務器可實現任何自定義傳輸協議，MCP 協議是傳輸無關的，只要支持雙向消息交換即可。
—— modelcontextprotocol.io
我們應該為最常見的使用場景做優化，而不是為邊角情況做妥協。
5.MCP的替代方案與補充
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 構建工具的手段。
這兩種協議最大的貢獻：更清晰的傳輸層設計 和 Agent 的發現機制。
6.網友：的確，文檔難懂是LLM廠商的通病等MCP適配器出來之后就好了
整篇文章，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://raz.sh/blog/2025-05-02_a_critical_look_at_mcp??
??https://news.ycombinator.com/item?id=43945993??
本文轉載自??51CTO技術棧??，作者：云昭
