你的 MCP 伺服器正在吞噬上下文窗口：其實有更簡單的方法

背景

隨著模型上下文視窗（Context Window）的擴張，開發者開始大量整合 MCP（Model Context Protocol）伺服器以賦予 AI 代理操作外部工具的能力。然而，這篇文章指出 MCP 存在嚴重的「上下文膨脹」問題，僅僅是載入工具定義與 JSON Schema 就可能消耗掉數萬個 Token，導致模型推理空間被大幅壓縮。作者提倡回歸 CLI（命令列介面）模式，利用漸進式揭露（Progressive Disclosure）的特性來優化 Token 效率。

社群觀點

Hacker News 的討論呈現出技術實務派與協議支持者之間的拉鋸。許多開發者認同 MCP 目前的 Token 消耗確實過於高昂，甚至有留言戲稱十年後的人們會驚訝於我們曾在如此狹小的上下文空間中掙扎。支持 CLI 模式的觀點認為，UNIX 哲學中的檔案與管道（Pipes）本就是最優雅的組合方式，讓 AI 透過執行指令並查看說明文件來探索功能，遠比預先載入數百個 API 定義更具效率。這種模式將「發現功能」的成本轉嫁給了模型推理的往返次數，雖然增加了延遲，卻換取了更乾淨的上下文空間。

然而，MCP 的核心維護者與支持者對此持有不同看法。他們指出「上下文膨脹」其實是一個過時的論點，因為現代的代理框架（如 Claude Code）已經實作了動態工具檢索（Tool Search），只會在需要時載入相關定義，而非一次性塞入所有 Schema。此外，MCP 提供的結構化規範在企業環境中具有不可替代的價值，特別是在安全性與權限控管方面。透過 MCP 註冊表，組織可以強制執行鏈式策略，例如禁止在讀取財務數據後進行網路搜索，而這種確定性的治理在純 CLI 或 Prompt 導向的「技能」模式中難以達成。

另一派觀點則從硬體與模型演進的角度出發，認為這只是過渡期的技術債。隨著上下文視窗邁向百萬等級，Token 成本將不再是開發者的首要考量。與其花費精力優化幾千個 Token 的 Schema，不如關注如何提升代理的可靠性。有留言指出，CLI 雖然在本地運行穩定，但對於非技術用戶而言，安裝與配置 CLI 的門檻極高，MCP 提供的託管式服務與統一協議更符合軟體消費化的趨勢。最終，這場爭論反映了開發者在「極致效能優化」與「標準化生態系統」之間的取捨，兩者在不同的應用場景下各有其存在必要。

延伸閱讀

在討論中，開發者提到了一些實用的工具與參考資源。例如 mcp2cli 是一個能將 MCP 伺服器轉換為 CLI 介面的開源工具，適合想兼顧兩者優點的開發者。此外，Scalekit 發布的基準測試報告詳細對比了 MCP 與 CLI 在不同任務下的 Token 消耗差異，是理解此議題量化數據的重要參考。針對企業級應用，Housecat 則展示了如何結合 Bash 執行與 CLI 封裝來構建更具彈性的 AI 代理架構。