為什麼 MCP 正逐漸過時：對模型上下文協定的批判性回顧

TL;DR – MCP 正在失去影響力

模型上下文協定（MCP）於 2024 年 11 月推出，如今已越來越不必要，因為現今的大型語言模型可以直接發現並呼叫 API 或命令列工具，消除了 MCP 伺服器所帶來的上下文膨脹與營運負擔。

MCP 最初的承諾

MCP 由 Anthropic 創建，旨在讓代理程式透過統一的 JSON‑RPC 介面存取外部服務。早期的模型需要一個輕量抽象層，將自然語言意圖轉換為具體的工具呼叫，而 MCP 迅速成為沒有終端機存取權限的代理程式的即插即用解決方案。

「MCP 於 2024 年 11 月由 Anthropic 團隊發布，作為一種協定，旨在幫助代理程式連接到外部服務和資料來源」【1】。

為什麼這個協定開始崩解

工具集不斷增長導致上下文膨脹

每個 MCP 伺服器都捆綁了許多工具，每個工具都有自己的 schema。當代理程式載入多個伺服器時，合併後的 schema 會壓垮模型的上下文視窗，迫使開發者修剪或代理工具。

「每個伺服器都會附帶多個工具，每個工具都有自己的 schema，這開始讓所有這些模型的上下文超載」【1】。

更好的模型可以直接生成和執行程式碼

現代代理程式（Claude Code、Meta Muse、OpenClaw 等）可以編寫腳本、組合多服務工作流程，並呼叫從未見過的 API。Cloudflare 的 Code Mode 展示了這一轉變，讓 LLM 生成沙盒腳本，而不是依賴 MCP 伺服器【1】。

「LLM 在這方面已經非常擅長，Cloudflare 甚至推出了 Code Mode，這是一種更好的 MCP 使用方式，讓 LLM 將各種呼叫組合成可在沙盒中執行的腳本」【1】。

透過 `--help` 直接發現 CLI

代理程式現在使用命令列工具的 --help 輸出推斷參數，消除了對單獨發現層的需求。

「LLM 已經學會如何使用 --help 命令來發現 CLI，因此它們不再需要 MCP 伺服器來存取許多服務」【1】。

社群的相反觀點

治理、認證與稽核能力

幾位評論者認為，MCP 仍然提供了一個受控的閘道，用於憑證處理、權限邊界和稽核日誌——這些是原始 API 或 CLI 存取所缺乏的功能。

「MCP 讓控制代理程式可以存取哪些外部服務變得更容易，處理認證而不暴露 API 金鑰，並提供強大的稽核日誌」 – @simonw。

企業級工具與外掛商店

商業使用者依賴 ChatGPT/Claude 市集中的一鍵 MCP 外掛，這些外掛捆綁了認證和 UI 整合。

「MCP 之所以勝出，是因為在 ChatGPT 和 Claude 應用程式中，有外掛商店。這些外掛是一鍵安裝的 MCP 伺服器，並支援認證」 – @whazor。

遠端控制情境

當代理程式必須與僅有 UI 的應用程式或沒有公開 API 的裝置互動時，MCP 伺服器可以暴露一個 socket 層級的指令協定。

「對於遠端控制一個沒有其他『存取點』的 UI 應用程式（例如遊戲引擎編輯器），MCP 伺服器仍然非常有意義」 – @flohofwoe。

何時直接 HTTP 或 CLI 優於 MCP

無狀態、文件完善的 REST 端點 – 代理程式可以附加 Accept: text/markdown 標頭（或類似標頭）來接收簡潔、代理程式友善的回應，而無需額外的 schema。
大型 JSON 負載 – 使用 jq 或 curl 搭配大小限制，讓代理程式可以迭代過濾資料，避免 MCP 冗長回應導致的 token 爆炸。
安全優先的環境 – 集中式認證和權限系統可以直接建置在 API 閘道中，消除了額外 MCP 層的需求。

「我們應該開始標準化代理程式如何直接使用 HTTP API。例如，代理程式用戶端可以附加標頭來識別自己為代理程式，伺服器可以自動以 Markdown 或文字形式發送回應資料」 – 作者。

新興實踐的真實案例

Accept‑Markdown 標頭 – 文件網站現在支援 Accept: text/markdown 來提供渲染後的 Markdown 而非 HTML，減少 token 數量。
Accept‑Language 用於 SDK 選擇 – Vercel 和 Shopify 使用語言偏好來提供特定語言的 SDK 範例，提高代理程式的相關性。

前進之路 – 不是二選一

社群的共識是細緻的：

在 MCP 提供獨特價值的地方保留它 – 受控的憑證處理、舊版 UI 自動化，以及企業外掛生態系統。
對簡單、無狀態的服務逐步淘汰 MCP – 用直接 HTTP 呼叫或 CLI 工具取代，代理程式可以透過 --help 發現這些工具。
標準化代理程式友善的 HTTP – 引入標頭（例如 User-Agent: agent/1.0）和內容協商格式，讓 API 對 LLM 來說像 MCP 工具一樣容易使用。

結論

MCP 是早期 LLM 的務實橋樑，但模型能力的快速提升、程式碼生成工具的興起，以及維護 MCP 伺服器的負擔，已經改變了成本效益的平衡。組織在投入 MCP 之前，應評估它是否仍解決了真正的問題——例如安全的憑證中介或遠端 UI 控制——否則應採用更簡單、效能更高且較不易上下文膨脹的直接 HTTP 或 CLI 方法。