從「全 MCP 化」到「重新發現 shell」
2024 下半年，社群一度認為 MCP 會把工具整合一統江湖。每個服務都該包成 MCP server、每個 agent host 都該支援 MCP、每個 workflow 都該透過 MCP 工具呼叫完成。我自己也跟風裝了一堆——GitHub MCP、Playwright MCP、Memory MCP、Sequential Thinking、Context7、Exa、Firecrawl……
但用了半年下來，一個趨勢很清楚：在 coding agent 的日常 workflow 裡，真正天天用、用到底的工具，幾乎都不是 MCP，而是 CLI。Claude Code 的 Bash、gh、git、kubectl、rtk、cmux，這些才是日常生產力的主軸。
這不是「MCP 失敗」（Anthropic 在 2025 年底還把 MCP 捐給 Agentic AI Foundation、ChatGPT/Cursor/Copilot 都加入支援，明顯是繼續擴張）。但對開發者使用 agent 寫程式這個場景而言，工具設計的鐘擺確實擺向 CLI。下面是我自己整理的五個原因。
原因一：context tax（預設實作下）你逃不掉
多數 MCP host 的預設行為，是把 server 上每個 tool 的 description、參數 schema、回傳格式說明，預先載入 prompt/tool context，不管這次對話會不會呼叫。Anthropic 自己的文件就寫過「MCP tool definitions 可能會占用 context 的可觀比例」；Playwright 官方也直接承認 MCP 模式 token 成本較高。
這個情況最近開始有解：Anthropic 推出了 MCP tool search，當 tool 定義超過閾值時改成 deferred loading；GitHub MCP 與 Playwright MCP 也都加了「縮減 context」的 flag。但這些是新功能，不是預設、不是所有 host 都支援。
所以實務上仍然是：掛幾個 MCP server，未動筆就先付幾千到幾萬 tokens 的稅。CLI 工具則完全不需要——gh pr list 不必事先告訴模型 gh 是什麼，訓練資料裡早有上千萬個 gh 範例，模型自己會用。
（粗略個人經驗：中等規模 MCP server 大概 5–10K tokens、5 個堆起來 30–50K，這是憑感覺的數量級，不是檢驗過的事實，請當參考。）
原因二：CLI 輸出能被攔截過濾，MCP 回傳難
CLI 的回傳是純文字 stream，可以串接過濾器：
rtk git log
rtk gh pr view 123
gh pr list --json title,state | jq '.[] | select(.state=="OPEN")'RTK 之所以能做出「Claude Code 省 50% token」這種效果，前提就是 CLI 輸出可以在進入 agent context 之前被攔截、壓縮、重排。
MCP 不是不能後處理——MCP spec 允許 text、image、audio、resource link 等多種 content block，Claude Code 也提供 PostToolUse hook 可以攔截 MCP tool 結果。但這些是 host/server 各自的擴展點，沒有 Unix pipe 那種「天然可以一行接一行」的組合性。我看過 Playwright snapshot 一次 5000 行直接灌進 context，那種時候只能祈禱 hook 有先攔到。
原因三：CLI 在「能跑 shell 的 agent」裡是真正可攜的
同一個 gh pr create，我可以在 Claude Code、Codex CLI、Aider、Cursor agent、Cline、Continue.dev 裡都跑得起來。指令不變，agent 換誰都行。
（一個我常見人搞錯的點：ChatGPT 的 Code Interpreter / Data Analysis 是 Python sandbox 不是 shell，gh 在那裡跑不起來，所以這條規則只適用於「真正能執行 shell 的 agent」。）
MCP 配置就比較碎。Claude Code 確實能 import Claude Desktop 的設定；Cursor CLI 跟編輯器共享 MCP 設定；Cline CLI 跟 VS Code 擴充也共享。但跨不同廠商仍然各搞一套——config 檔位置、安裝路徑、環境變數都不同，要在 Claude / Cursor / Cline / Codex 之間搬整套 MCP，幾乎一定要重配一次。對「想用最強 agent 解最棘手問題」的人來說，CLI 還是更可攜的工具語言。
原因四：除錯透明度
CLI 出問題我能看到完整 trace：command line、stdout、stderr、exit code，全部留在 terminal log 裡。
MCP 出問題往往要兩邊比對：tool 回了空陣列？是 server 沒抓到、還是 schema 解析錯誤、還是 host 端 timeout？通常要去翻 host console，加上 server 端 log。
當 agent autonomous 跑半夜八小時，這個透明度差距會被放大：CLI 的失敗模式，agent 自己讀 stderr 就能修；MCP 的失敗模式，agent 經常只能放棄或 retry 到累。
原因五：延遲
很多 MCP server 是 stdio 子程序或 container，每次首次呼叫要走 handshake、初始化；遠端 MCP 還要走 HTTP/SSE。一個熱好的 shell、或一支已經編譯好的 binary（像 RTK），對「快速查一下」的請求快上一個量級。
對 agent 來說，這個差距不只是速度，也是「願不願意輕量地查一下」的成本門檻——便宜的工具會被多用、貴的會被慢慢避開。
那 MCP 還活在哪？（其實不少）
我並不主張全盤拔掉 MCP。它在這幾類場景仍然強：
Stateful session：Playwright MCP 維持瀏覽器 process、保留 cookie 與 page state。用 CLI 重做不合理。
結構化資料：knowledge graph、accessibility snapshot 的樹狀資料，比起純文字更適合走 MCP 的 content block。
嚴格權限邊界：當你需要明確控管 agent 能做什麼（不允許執行任意 shell），MCP 的 tool whitelist 比開放 Bash 更安全。
Resources 與 prompts：MCP spec 提供 resources（agent 可讀取的內容）與 prompts（預設好的請求模板），這是 CLI 沒有對應結構的地方。
遠端 OAuth 服務：例如 Linear、Notion、Atlassian 這類有正式 OAuth 流程的 SaaS，MCP connector 比讓 agent 自己處理 token refresh 乾淨太多。
給非工程使用者的 discovery：在 Claude Desktop 把 Google Calendar 接進來，按一個 button 就能用。對非寫程式的使用者，MCP 的 GUI/menu 比 CLI 友善得多。
還有一個介於兩者中間的設計：Anthropic 的 Agent Skills。Skills 兼有 MCP 的 discovery（在 system prompt 看得到列表），但執行時會 lazy-load skill 內容，最後仍是用 Bash/CLI 跑事情，相當於「MCP 的尋找便利 + CLI 的執行成本」。
實務建議：從減法做起
如果你現在的 Claude Code（或其他 agent）掛了一堆 MCP，我會建議：
看一下哪些 MCP 真的有在用、哪些只是在燒 context。
把「每月用不到一次」的 MCP 全部拔掉。
能用 CLI 替代的（GitHub、檔案、grep、git），改用 CLI + 過濾器（RTK 之類）。
剩下保留：瀏覽器、結構化資料、權限邊界、遠端 OAuth、組織共用整合。
我自己的設定大概從 12 個 MCP 砍到 4 個，agent 反而更聰明、回應更快、context 在長 session 撐得住。
結語：鐘擺擺到中間
這不是「MCP 失敗」的故事，更像是工具設計的鐘擺從「all-in MCP」擺回中間。LLM 終究是一個讀過幾兆行 shell command 的物種，給它 terminal 它就能用整個 Unix 生態系；給它 MCP，它能用你裝的那幾個 tool——兩種抽象層級，各有適合的場景。
對 coding agent 來說，未來看起來會是：CLI 當主菜、Skills 當索引、MCP 當特殊用途。「萬物皆 MCP」的那一波熱潮，已經退到比較合理的位置。