有人量過一個數字：一個掛了 106 個工具的資料庫 MCP server，光初始化就吃掉 54,600 個 token，什麼事都還沒做。同樣的操作用 CLI 做，一次呼叫加 shell 過濾，大約 1,400 個 token。四十倍的差距，「MCP sucks」的論戰就這樣燒了起來。

這場論戰吵錯了題。那個數字量到的是一個設計錯誤：把 106 個無狀態的查詢操作硬包進常駐協議，每次對話載入全部 schema，成本自然是 schema 大小乘以工具數量，Day 17（Tool Design）的老問題再現。但「有人用錯 MCP」推不出「MCP 沒用」。三種整合方式要擺對位置，該問的只有：你在解的，是一台機器的問題，還是一個組織的問題？

一台機器的問題：CLI 是人和 agent 的共用介面

CLI-as-Tool 的力量來自一個常被忽略的事實：LLM 在訓練資料裡已經看過幾乎所有主流 CLI 的完整用法。git、kubectl、gh、jq，agent 不需要任何說明書。token 最省之外，還有個定位優勢：人和 agent 用同一個介面。production 出問題，你在 terminal 跑同一行指令就能重現，除錯不隔層。

它的弱點也是尺度給的：每次呼叫是獨立的 subprocess，跑完就死，狀態帶不走；credential 散在本機設定裡，五個 agent 就是五份；誰在什麼時候用了什麼工具，沒有地方記錄。一台機器、一個使用者，這些都無所謂；放到一個組織，每一項都是待辦事項。

直呼 API 則更輕：工具定義裡直接寫一個 HTTP call，適合一次性操作，代價是沒有複用性。它的定位是膠水。

一個組織的問題：MCP 在解分發、授權、觀測

MCP 的定位要從它解的問題讀出來。傳統形態的 MCP server 是常駐進程，持有活的資源：登入中的 browser session、資料庫連線池、已認證的企業帳號，多次呼叫對著同一個活資源操作。它難被取代的部分是治理：五個 agent 共用同一個 Jira 帳號時，OAuth token 集中在 server 手上，agent 從頭到尾碰不到 secret。

GitHub 的例子把定位問得更清楚：gh 這麼好用，為什麼還要出官方 MCP？因為跑在 SaaS 平台、Electron 沙盒裡的 agent，環境裡根本沒有 terminal、沒有 $PATH，gh 裝不進去。MCP 是為「工具要分發到你控制不了的環境」而存在的，這件事 CLI 在結構上做不到。

四個問題，順序問下來

選之前把協議偏好放一邊，先問工具本身：

1. 工具有現成介面嗎？ 有 CLI 直接用；有 OpenAPI spec 可以自動生成 agent 友善的 CLI（開源工具 cli-printing-press 做的就是這件事）；都沒有才考慮更重的方案
2. 連線需要跨呼叫存活嗎？ 一個指令一個結果，CLI 夠了；需要登入狀態、session 脈絡，才輪到 MCP
3. 幾個 agent 要共用這個資源？ 單 agent 自己管 credential 還行；多 agent 共用帳號或連線池，集中管理的 MCP gateway 才值得
4. 執行環境有 terminal 嗎？ 有 terminal 的環境幾乎永遠有更簡單的方案；沒有的（SaaS、沙盒）才是 MCP remote 的主場

四題問完，多數場景的答案自己浮出來：本機開發的 coding agent 用 CLI、企業多 agent 平台用 MCP gateway、輕量 webhook 直呼 API。不過這四題的權重，2026 年中被 MCP 自己動了手腳。

2026-07-28：MCP 自己回答了定位問題

MCP 在 2026-07-28 版規範改了體質（連結在文末），三個改動讀下來，它對自己的定位比任何論戰文都誠實。

它主動拆掉了「有狀態」這個賣點。 新規範把 initialize 握手和協議層 session 整個拿掉，協議變成純 request/response：load balancer 後面任何一個 instance 都能接任何請求，server 可以跑 serverless 和 edge，官方說法是一級的 HTTP workload。工具清單的回應也變成可快取，54,600 token 那類 schema 全載成本被協議自己稀釋。第二題（連線要不要跨呼叫存活）的權重就這樣降了：連 MCP 都不再把「持有連線」當核心理由。

狀態沒有消失，它從連線搬到了任務身上。 長時間工作改走 Tasks 擴展：tools/call 可以先回一個 task handle，client 拿著它查進度（tasks/get）、取消（tasks/cancel）。這個模式你在 Day 18（Agentic Loop）看過：一次執行是有身份、可查詢、可取消的狀態機，現在這個 run 模型被寫進了協議層。這一步的判斷值得學：狀態綁在傳輸連線上，斷線即遺失、擴展要 sticky session；綁在任務上，狀態落地、連線只是觀看視窗，無狀態核心和長任務就不再互相矛盾。

治理從附帶好處變成主力。 授權對齊生產級 OAuth 2.0 與 OIDC：issuer 驗證、憑證綁定授權伺服器，企業授權擴展讓 Okta、Entra 這些身份系統原生接上，再配上連接器目錄和效能儀表板。「誰能用哪個工具、用了之後看不看得見」被做進協議本身，第三題（多 agent 共用與治理）的權重同步上升。

收束成一句：MCP 的定位從「更好的工具呼叫方式」轉成「工具的治理與分發層」。它和 CLI 的關係也跟著清楚了：CLI 管一台機器，MCP 管一個組織，各自在自己的尺度上都是預設答案。

L3 的零件講完了，最後一題

八天下來：session、工具、agentic loop、權限、skills、multi-agent、對外介面。零件全部在桌上，但一路都是一天一個切片，收官前欠一個視角：裝在同一台機器上，這些零件彼此怎麼咬合？明天把零件組回去，用一個讀得到原始碼的系統走完全程，然後誠實面對這一層的極限。收官 Harness Engineering（這系列的 L3）。

參考：The 2026-07-28 Specification（MCP 官方）、Bringing MCP 2026-07-28 to Claude（Anthropic）