Is MCP Dead? Evaluating the Model Context Protocol vs. CLI-First Strategies
Model Context Protocol (MCP) 被譽為「AI 生態系統的 USB-C」，承諾提供一個通用標準，將大型語言模型 (LLM) 連接到 GitHub、Slack 和 Notion 等外部工具。然而，隨著開發者從早期採用轉向日常生產環境使用，一場激烈的辯論出現了：MCP 是一個優雅的解決方案，還是一個阻礙效能的過度設計層？
來自 Quandri 工程團隊的最新分析指出，對於許多開發者工作流程來說，MCP 可能是一個不必要的抽象。透過將 MCP 與「CLI 優先」策略和「Skills」模式進行比較，他們認為該協定在上下文消耗（context consumption）和操作可靠性方面經常引入顯著的開銷。
反對 MCP 的理由：上下文與可靠性
對 MCP 的主要批評集中在它如何利用 LLM 的上下文窗口（context window）。在標準的 MCP 設定中，工具定義（告訴 LLM 工具功能及其呼叫方式的 schema）通常會預先載入。
「上下文膨脹」問題
Quandri 的測量結果顯示，工具定義會吞噬驚人的上下文窗口空間。在他們的技術棧中，僅僅連接四個 MCP 伺服器（Linear, Notion, Slack, 和 Postgres）就消耗了約 21,077 個 tokens。對於像 GPT-4o 這樣擁有 128K 窗口的模型來說，在實際工作開始前，已有 16.5% 的可用「桌面空間」被佔用了。
Linear 是一個特別極端的例子，其中 42 個工具定義佔用了超過 12,800 個 tokens。這意味著模型必須背負所有可能的 Linear 操作，即使使用者只需要呼叫單個 get_issue。
操作開銷
除了 tokens 之外，MCP 的架構層還引入了幾種操作摩擦：
- 延遲 (Latency)： 每次 MCP 呼叫都會在 LLM 與 API 之間增加一個處理層。基準測試顯示，MCP 的速度明顯慢於直接的 REST API 呼叫，尤其是在初始化期間。
- 可靠性 (Reliability)： MCP 伺服器是獨立的進程，可能會在會話中崩潰或在身份驗證期間失敗，導致 AI 對話中出現不明錯誤。
- 冗餘 (Redundancy)： 對開發者而言，MCP 通常與現有的命令列介面 (CLI) 重疊。如果一個工具已經擁有穩定的 CLI，建立 MCP 伺服器往往意味著以一種較低組合性的格式重新建立相同的功能。
替代方案：CLI 優先與 Skills 模式
為了緩解這些問題，一些團隊正在採用 CLI 優先策略 (CLI-First Strategy)。他們不是提供專用的協定，而是向 LLM 提供 CLI、API 文件和必要的環境變數。這種方法利用了 LLM 已經在大量 man pages 和 StackOverflow 數據上進行過訓練的事實。
Skills 模式
如果說 MCP 被描述為「預先將所有菜單鋪滿桌面」，那麼 Skills 模式 就類似於「只向圖書館員索取你需要的書」。
在這種模式下，LLM 僅在呼叫特定技能時，才會載入該工具的特定指令（例如，用於 Linear 議題查詢的 curl 指令）。這可以防止上下文窗口被未使用的工具定義永久佔用。例如，透過 CLI 進行 Linear 查詢可能僅需 ~200 tokens，而 MCP 方式則需要 ~12,957 tokens。
反對意見：為什麼 MCP 仍然重要
儘管有這些批評，許多業界專家（包括 OpenAI 的專家）認為「MCP 已死」的說法忽略了大局。該協定的價值不在於傳輸層，而在於服務發現的標準化 (standardization of service discovery)。
非開發者的易用性
CLI 對工程師來說很強大，但對於 HR、財務或行銷團隊來說卻是門檻過高。MCP 提供了一種方式，讓非技術用戶可以透過 UI（如 Claude 或 ChatGPT）連接服務，而無需安裝二進位檔案或管理 SSH 金鑰。
安全性與護欄 (Guardrails)
支持 MCP 的最強有力論點之一是安全性。基於 CLI 的代理（agent）有權執行使用者擁有權限的任何命令，包括在資料庫中執行 DROP TABLE。然而，MCP 伺服器可以作為安全代理，在查詢到達資料庫之前，在伺服器層級強制執行唯讀模式並驗證查詢。
API 的「長尾效應」
並非每個服務都有 CLI。許多 SaaS 產品僅提供 Web 介面或複雜的 API，這些 API 並非為 LLM 消耗而設計。MCP 允許這些公司建立一座「橋樑」，讓他們的服務具備代理就緒（agent-ready）的能力，而無需強迫使用者編寫自定義的封裝腳本。
綜合分析：選擇正確的工具
這場辯論表明，在 MCP 與 CLI 之間進行選擇並非二選一，而是基於使用場景的光譜選擇：
| 場景 | 建議方法 | 理由 |
|---|---|---|
| 本地開發 / 個人工具 | CLI + Skills | 最大化速度，最低的 token 成本，在終端機中易於除錯。 |
| 企業 / 團隊協作 | MCP | 集中式驗證、權限範圍劃分，以及更簡單的非技術用戶上手流程。 |
| 生產環境資料庫 | MCP | 對查詢安全性和存取控制至關重要。 |
| 無 CLI 的 SaaS | MCP | 提供結構化工具存取的唯一可行方式。 |
結論
隨著生態系統的演進，MCP 的技術摩擦（如上下文膨脹）正在得到解決。諸如 具備延遲載入功能的工具搜尋 (Tool Search with Deferred Loading)（已在 Claude Code 中推出）等功能，透過按需載入 schema，已經減少了超過 85% 的上下文使用量。
最終，目標並非尋找單一的「勝出」協定，而是優化資訊流。無論是透過精簡的 CLI 還是強大的 MCP 伺服器，首要任務始終如一：盡量減少上下文窗口中的雜訊，並最大化工具執行的可靠性。