TL;DR：MCP 消耗大量上下文，可靠性低，且與現有 CLI/API 功能重疊。
參考：MCP 已死。長存 CLI
在閱讀上述文章後，我們在實際的技術堆疊上進行了實驗。本文涵蓋了原始論點、額外研究以及我們的測量結果。
更新：自這些測量進行以來，Claude Code 已推出具有延遲載入的工具搜尋功能，該功能會按需載入 MCP 工具綱要，並將上下文使用量減少 85% 以上。對於目前使用 Claude Code 版本的用戶來說，第一點所述的上下文膨脹問題已大致解決。然而，下述的效能、除錯和架構論點仍然適用。
MCP（Model Context Protocol）將大型語言模型（LLM）連接到外部工具（如 GitHub、Linear、Notion、Slack 等）。
自 2024 年底推出以來，它被譽為「AI 生態系統的 USB-C」。但實際日常使用的開發者們開始有了不同的看法。
TL;DR：MCP 消耗大量上下文，可靠性低，且與現有 CLI/API 功能重疊。
上下文視窗是 LLM 的桌面。當您連接 MCP 伺服器時，僅工具定義就佔用了該桌面相當大的空間。
我們提取並測量了我們環境中連接的 MCP 伺服器上的實際工具定義。連接所有 4 個伺服器後，僅工具定義就佔用了上下文視窗的 10.5%。
僅 Linear 就佔用了超過 12,800 個 token。這意味著始終載入 42 個工具定義，即使您只使用 `get_issue` 和 `save_issue`。
效能是一個已知問題。原始文章的作者將 Jira MCP 與其 REST API 直接進行了基準測試，發現 MCP 每次呼叫的速度慢了 3 倍，首次呼叫（包括初始化）速度慢了 9.4 倍。這並非 Jira 特有，而是架構性的問題：每個 MCP 伺服器都會在 LLM 和底層 API 之間增加一個處理層。同樣的開銷也適用於我們技術堆疊中的 Linear、Notion 和 Slack 伺服器。
查詢同一個 Linear 問題需要多少 token？MCP 比 CLI 方法消耗的 token 多約 65 倍。
請依序提供 CLI -> API -> 文件。LLM 已經從 man pages 和 StackOverflow 中學習了。
如果 MCP 是「將所有菜單都攤在桌面上」，那麼 Skills 則是「只向圖書館員索取您需要的書」。
關鍵在於將 CLI 使用說明嵌入 Skills 中。結合替代方案一的 CLI 優先策略，這是最高效的。例如，一個 Linear Skills：
這樣，LLM 只會在調用 Skills 時將上述內容載入上下文。無需始終攜帶 42 個工具定義。只需要它需要的 CLI 命令。
並非完全如此。MCP 在以下情況下仍然有效：
資料庫最終只是查詢執行。LLM 已經很熟悉 SQL 和 MongoDB 查詢。將資料庫資訊和 CLI 使用方法放入 Skills 中，無需 MCP 即可正常工作。只需提供綱要，它就能編寫查詢。
然而，MCP 對於資料庫有其優勢：
但對於大多數開發者工作流程而言，MCP 是過度設計。
如今，每個 SaaS 登陸頁的特色列表中都標有「支援 MCP」。無論 MCP 伺服器是否穩定或消耗多少上下文都不重要——目標是勾選「我們也支援 MCP」的方框。這與幾年前的「AI 驅動」和「區塊鏈基礎」的行銷模式相同。當用戶實際連接時，他們會遇到數十個工具定義載入失敗、初始化失敗以及中間會話崩潰。
在 Quandri，我們同時使用這三種方法，根據每項服務的適用性進行選擇：
我們不會強迫採用單一途徑。如果已經存在一個 CLI 並且可以在本地進行身份驗證，那通常是最輕量級的選擇。如果某個服務沒有 CLI，或者我們需要在團隊之間實現統一的身份驗證，MCP 就能發揮其作用。
良好的教學比連接一切更重要。
對我們而言，用封裝現有 CLI 的 Skills 取代 MCP 伺服器，釋放了約 21,000 個 token 的上下文，消除了日常工作流程中的初始化失敗，並將除錯保留在終端機中，這才是它應有的位置。
僅在需要時載入您需要的工具，並內嵌 CLI 指示。MCP 可能會演進以解決這些問題，但目前，Skills 是贏家。
測量方法：工具定義大小是透過從我們 Claude Code 環境中實際載入的 MCP 伺服器提取每個工具（名稱 + 描述 + 參數）的 JSON 綱要來測量的。Token 估計使用約 4 個字元/token 的估算方法。完整的伺服器估計是從抽樣工具平均值推斷出來的。
Chloe 是 Quandri 的後端工程師。她對 AI 工作流程、代理原生工程以及 AI 如何改變軟體建構方式感興趣。