MCP 已死；MCP 萬歲

背景

Model Context Protocol（MCP）在推出之初曾引發極大的市場熱潮，被視為連接 AI 模型與外部工具的標準化橋樑。然而，隨著開發者實際投入使用，社群開始反思其過度包裝與 API 封裝帶來的額外負擔，甚至出現了 MCP 已死的質疑聲浪，轉而擁護更傳統、直接的命令列界面（CLI）工具。

社群觀點

Hacker News 的討論呈現出兩極化的趨勢。經驗豐富的開發者傾向於對這類新興協議保持戒心，認為 MCP 與先前的 LangChain 類似，存在過度工程化的問題。反對者指出，對於個人開發者而言，直接編寫針對 REST API 的輕量級封裝或使用 CLI 工具更為高效，因為 CLI 工具如 curl 或 git 早已存在於模型的訓練數據中，模型無需額外指令即可精準調用，這能大幅節省 Token 消耗並避免預先載入大量 Schema 造成的上下文膨脹。

然而，支持者則從企業協作與標準化的角度提出反駁。他們認為 MCP 的核心價值不在於個人開發，而是在於組織內部的中心化管理。當一個團隊擁有數十名工程師使用不同的 AI 代理工具時，MCP 提供了一個統一的通訊語言、身份驗證機制與遙測監控手段。透過 MCP 伺服器，企業可以確保所有開發者無論使用哪種編輯器，都能獲得一致的工具能力與文件支援。此外，MCP 支援的結構化輸出與輸出 Schema 被認為是極具潛力的特性，特別是在配合 CodeAct 代理模式時，能讓模型透過撰寫程式碼來調用工具，進而達成顯著的 Token 節省，這點是傳統 CLI 難以企及的技術優勢。

社群中也有一派觀點認為，這場爭論反映了 AI 產業被網紅行銷驅動的焦慮感。許多技術選型並非基於工程優劣，而是為了製造錯失恐懼（FOMO）。儘管如此，部分開發者分享了實際獲益的案例，例如利用 MCP 快速建立資料庫的 CRUD 介面，讓 AI 能以自然語言進行除錯與測試數據準備。最終，社群的共識傾向於：MCP 並非萬靈丹，它在需要跨平台一致性、權限控管與複雜結構化互動的企業場景中具有不可替代性，但對於追求極簡與效能的個人任務，傳統的 CLI 或直接 API 調用依然是更明智的選擇。

延伸閱讀

在討論中，開發者提到了幾項值得關注的技術資源，包括 Hugging Face 關於 smolagents 與輸出 Schema 的技術實作，這展示了如何透過結構化協議提升代理效率。另外，Anthropic 推出的程式化工具調用（Programmatic tool calling）以及 Cloudflare 的 Code Mode 也是觀察 MCP 演進的重要案例。針對 CLI 與 AI 技能的整合，社群也推薦參考 CLI Skills Protocol 的設計理念，作為 MCP 之外的另一種思考路徑。