MCP 已死了嗎？2026 年這場爭論，該退場的是那種接法而不是協定
2026 年 5 月，一篇標題叫〈MCP is dead?〉的文章衝上 Hacker News；2 個月後，同一個協定發布了問世以來最大的一次改版，官方揭露開發套件每月下載接近 5 億次。這篇把唱衰的具名批評逐項打開查證，看哪幾項成立、官方承認了哪一項，以及零售品牌該把採購問句換成什麼。
如果你最近在主管群組裡收過一則轉貼，標題大意是某個 AI 接口標準已經退流行，這篇是寫給你的。那個標準叫 MCP（Model Context Protocol，模型上下文協定），它決定 AI 能不能連到你的會員、訂單與庫存系統，所以「它死了沒」這個問題，會直接影響一筆採購怎麼決定。
宣告死亡與創下新高，發生在同一個夏天
2026 年 5 月 29 日，一篇標題只有三個字加一個問號的文章被丟上技術社群 Hacker News：〈MCP is dead?〉。它累積到 400 分、410 則留言（2026 年 9 月 6 日查核）。留言區的技術人拿出實際量測，說這個協定吃掉的資源不成比例，說既有的命令列工具早就做得更好。
2 個月後，2026 年 7 月 28 日，同一個協定的維護團隊按下發布鍵，推出問世以來改動幅度最大的一版規格。官方公告在開頭寫了一句話：官方分級為第一級的幾套開發套件，每月下載量接近 5 億次。
同一個夏天，同一個協定。一邊是熱門討論串把它宣告死亡，一邊是官方數字在往上走。這兩件事都是真的，而它們同時為真這件事本身，就是零售品牌最該讀懂的訊號。
我們擔心的不是唱衰，是它把採購問題壓成了是非題
我們最近幾次跟品牌談 AI 工具接入，對方開場常常是同一句：聽說 MCP 已經退流行了？再問下去，多半是主管群組裡有人轉了一則貼文，標題很聳動，內文沒人讀完。
我們擔心的不是有人在唱衰。技術圈的爭論通常會讓東西變好，這次也是。我們擔心的是這種聽說會把一場本來該問「這家廠商是怎麼接的」的採購對話，壓縮成「要不要接」的是非題。是非題答錯只有兩種結果：該接的沒接，或是不該那樣接的照樣接了。
「MCP 已死」這句話，混合了不同層次的問題
把幾個月來轉得最凶的主張攤開排一排，會發現它們其實不在同一個層次上吵架。有些在講協定本身的設計，有些在講別人寫的伺服器有多糟，有些則是在講「在他自己的工作流裡用不到」。這三件事的結論完全不同，混在一起講就會得出「已死」這種過於乾脆的答案。本文為了讓討論可以進行，把常見主張分成協定層、實作層與使用情境層三類來看。
| 常見主張 | 它實際上在講哪一層 |
|---|---|
| 這個協定吃掉太多上下文視窗 | 實作層：伺服器掛了幾個工具、用戶端有沒有按需載入 |
| 命令列工具就夠了，不需要協定 | 使用情境層：單機開發者的日常，與組織要管幾百個人的授權，是兩種問題 |
| Agent Skills 出來之後它就多餘了 | 範疇錯置：一個管通道，一個管流程 |
| 協定的設計本身有問題 | 協定層：唯一真的在批評協定的那一項 |
上下文視窗指的是模型一次讀得進去的文字上限。工具定義掛在那裡不呼叫也照樣佔位，這是後面幾段爭論的共同起點。如果對這個協定本身還沒有底，先看這個協定讓 AI 接進你的系統有了共同規格、而通道要開多大仍然是品牌自己的決定那篇，再回來看這場爭論會比較有感覺。
範疇錯置那一列最容易釐清，因為提出這兩套規格的是同一家公司，而它自己講得很明白。Anthropic 在 2025 年 10 月 16 日介紹 Agent Skills 的官方工程文章裡寫的是「探索 Skills 如何補足 MCP 伺服器」，用的字是補足。至於Prompt、MCP 與 Agent Skill 各自回答哪一個工作問題、行銷團隊最常搞混的三個誤解，站上有一篇用會員回購任務走過一遍，這裡不重做定義。
其餘的主張，值得一項一項打開來看。
唱衰 MCP 的人，實際上寫了什麼
這一段刻意只收具名、可查到原文的批評。轉貼二手摘要的版本一律不採用，因為這場爭論裡被扭曲得最嚴重的，正好就是那些沒人回去讀原文的部分。
工具愈多，模型愈容易在相似選項裡挑錯
時間最早、影響最深的一篇來自 Armin Ronacher，發表於 2025 年 8 月 18 日，標題叫〈Your MCP Doesn't Need 30 Tools: It Needs Code〉。他的核心句子是：工具愈多，你就愈是在製造 context rot，也就是模型讀進去的那一大段內容彼此稀釋、判斷跟著鈍化。他舉的例子是一套網頁自動化工具的 MCP 伺服器，原本對模型攤開大約 30 個工具定義。
這一項成立。工具清單變長，模型要在一堆功能相近的選項裡挑出對的那一個，選錯或混淆的風險會跟著上升。
但他寫這篇的結論不是棄用 MCP。他開的藥方是反過來的：做一台只暴露 1 個工具的伺服器，那個工具吃程式碼。把 30 個工具收成 1 個，工具定義的體積跟著垮下來，而且模型可以用它本來就熟的語言去組合動作。他在修的是伺服器的設計，協定本身沒有被他判死刑。
有人真的不用了，但那句話常常被剪掉一半
2025 年 11 月 4 日，Simon Willison 在自己的網站上寫下那句被轉最多次的話：跟編碼代理一起工作時，他已經完全不用 MCP 了，命令列工具對他更有效率。
這句被剪下來當成「連他都不用了」的證據，可是同一篇他的另一句評語是：Anthropic 當天發布的那份改良提案「這整套看起來很扎實」。他挑的毛病是提案講得很細卻沒附上可以直接跑的程式碼，不是協定該廢。
對品牌來說，這一段的用處在於劃出適用邊界。一個工程師描述自己一個人的工作流用不到某樣東西，跟一家公司要讓幾十位行銷同事共用同一套工具、而且要能隨時收回某個人的權限，是兩種規模的問題。把個人心得當成組織結論，是這場爭論裡最常見的推論失誤。
把整份帳單量出來的那一篇，後來自己加了註
被丟上 Hacker News 引爆討論的那篇，出自 Quandri 的工程師 Chloe Kim，標題就是〈MCP is dead?〉。它之所以有殺傷力，是因為它不談感覺，它算。
| 掛上去的伺服器 | 工具定義估算佔用 |
|---|---|
| 專案管理工具（42 個工具） | 約 12,807 個 token，佔 20 萬 token 視窗的 6.4% |
| 4 台伺服器合計（77 個工具） | 約 21,077 個 token，佔 10.5% |
換句話講，在使用者打第一個字之前，光是告訴模型「你手上有這些東西可以用」，就已經先花掉了十分之一的上下文視窗。這裡要把方法講清楚：原文標的是估算 token，作法是擷取實際的工具定義文字，再用大約 4 個字元換 1 個 token 去推算，整台伺服器的數字則由抽樣的工具平均值外推。這是量級的參考，不宜當精算看。這筆常駐開銷怎麼換算成品牌算得出來的三筆帳，也就是工具清單的入場費、選錯工具的返工費，以及維護工具吃掉的機會成本，站上有一篇整理過算式，這裡不重複。
有兩件事，轉貼這篇的人幾乎都沒提。
其一，這篇的結論不是死了。作者的判斷是 MCP 在幾種情況下仍然站得住：純網頁的軟體服務、不是開發者的使用者、需要雙向即時溝通的場景。她的建議是有現成命令列工具而且本機就能完成登入時，那通常是最輕的選項。
其二，原文後來加了一則更新註記：自從那些量測完成之後，Claude Code 已經推出按需載入的工具搜尋機制，MCP 的工具定義改成需要時才載入，上下文用量下降超過 85%。
一篇被當成死亡宣告轉了幾個月的文章，作者本人沒有這樣寫，而且她量到的那個問題，在她自己的頁面上已經標註為大致被處理掉了。
最直接的那一篇，前提藏在標題外面
2026 年 2 月 28 日，Eric Holmes 發表〈MCP is dead. Long live the CLI〉，標題沒有問號。他的論點乾淨俐落：命令列工具經過幾十年的設計迭代，可組合、可除錯，而且直接沿用早就存在的登入機制。他的收尾是「MCP 想蓋一個更好的抽象層，結果我們本來就有一個不錯的」，給企業的建議是「先做一個好的應用程式介面，再做一個好的命令列工具，代理自己會弄懂」。
這一項在他描述的場景裡成立。但它有一個沒寫進標題的前提：你得先有那個命令列工具，而且授權問題已經解決了。
對工程師來說，這兩件事通常是既成事實。對一個要讓四十位行銷同事都能用同一套工具、還要能在有人離職那天立刻收回權限的品牌來說，這兩件事就是整個專案。把長效金鑰寫在設定檔裡讓每個人自己保管，跟由公司的帳號系統統一發放、統一撤銷，是兩種治理成本。我們寫過一篇談當 AI 變成一種非人類身分在系統裡活動，權限、稽核紀錄與收回機制要怎麼跟著它走，那是這個前提被拆開之後真正要面對的工作。
協定的維護者，把同樣的問題寫進了自己的路線圖
如果批評成立，通常會有兩種發展。一種是被維護者無視，另一種是被吸收進規格。這件事有公開紀錄可以查。
先看提出協定的公司自己怎麼講。Anthropic 在 2025 年 11 月 4 日的官方工程文章裡，把問題點名成兩條：工具定義塞爆上下文視窗，以及中間過程的工具結果又吃掉額外的 token。同一篇示範的做法是讓模型寫程式去取用，並用一個示例估算，把用量從 150,000 個 token 壓到 2,000 個，省下 98.7%。那是該文的示例估算，換一個環境不會是同一個數字，但它承認問題存在這件事沒有模糊空間。
再看規格。2026 年 7 月 28 日這一版的官方變更紀錄有幾項對著上面的爭論來，各自解決的問題不一樣，值得拆開講：
- 工具清單的回應開始帶快取時效，並要求伺服器用固定順序回傳工具。它處理的是「同一份清單每次重抓一遍」的重複成本，讓上游快取在重新連線之後保持穩定。它沒有讓工具定義從上下文裡消失。
- 協定核心改成無狀態，連線前的握手流程整個拿掉，方法名與工具名改由網路封包的標頭帶著走。對品牌的白話意義是：這種伺服器可以像一般網站服務一樣做負載平衡，而且公司的閘道器不必拆開內容就能記錄與擋下不該過的請求。
- 授權那一塊做了硬化，舊的動態註冊方式被正式標為淘汰，並且訂了 12 個月的最短淘汰窗，讓接的人有時間排時程。
員工授權該由誰統一管，是另一條線。2026 年 6 月 18 日，官方發表企業託管授權擴充，處理的正是每個員工各自去授權每一台伺服器、資安團隊沒辦法執行一致政策這個痛點。
最能說明問題的是路線圖。2026 年 8 月 22 日更新的官方路線圖列了 5 個優先領域，其中改良原語那一項底下寫著一個叫漸進式探索的工作，說明文字是：讓用戶端在需要的時候才學到伺服器有哪些工具與資源，而不是一開始就把整份目錄吞下去。同一份路線圖在講代理身分那一段時，也直接承認現有的 MCP 伺服器仰賴貼上去的金鑰與長效權杖。
這裡要把話講準。官方沒有說「全部預先載入」這種接法已經被規格淘汰，漸進式探索目前的狀態是列在路線圖上的優先工作，而路線圖本身明載那是目前的構想、不是承諾。可以確定的只有一件事：路線圖處理的問題，跟外界罵得最凶的那幾項高度重合。一個協定的維護者把這些問題排進自己的優先事項，這是批評有效的證據。
同一段期間的其他動作也不像在收攤。2026 年 1 月 26 日，MCP Apps 成為第一個官方擴充，讓工具可以回傳直接在對話裡顯示的互動介面，這件事是 Anthropic、OpenAI 與 MCP-UI 社群一起做的，Claude、Goose、Visual Studio Code 與 ChatGPT 都已經支援。
廣告平台這一端更能回答「到底有沒有人認真在用」。Google 推出官方的 Google Ads MCP 伺服器時，刻意只給查詢不給寫入，能跑報表、能診斷，但不能改預算也不能開關廣告。一個平台願意花力氣做一台，又主動把手綁起來，代表它把這條通道當成要長期經營的東西而不是一次性的宣傳品。為什麼是唯讀、自架與開放寫入的路徑各自要付什麼代價，站上拆過那個設計選擇。
Meta 那一端的取捨走另一個方向，把不少開關留給商家自己設定，於是接得上不等於接得安全、有哪幾格權限預設是開著的、以及它做不到什麼就成了接之前該先看清楚的事。兩家的處理方式不同，但都不是隨手做一個交差的樣子。
治理層面也早就不在單一公司手上：2025 年 12 月 9 日，MCP 捐給了 Linux 基金會旗下的 Agentic AI Foundation，由 Anthropic、Block 與 OpenAI 共同創立，官方在公告裡把界線講得很清楚：基金會提供中立的家與基礎設施，不會指導 MCP 的技術方向。
那則公告當天揭露的數字是每月開發套件下載超過 9,700 萬次、1 萬個活躍伺服器；7 個多月後，官方講的是第一級開發套件接近 5 億次。兩期的統計範圍與計算方式官方沒有完整公開，不宜換算成精確增幅，也不能直接等同企業採用數或實際使用深度。能說的是：至少在官方自己追蹤的開發套件下載活動上，這個生態仍然明顯熱著。
這篇沒有回答的那幾項批評
到這裡看起來像是幫協定講話，所以要把難聽的部分也講完，否則這篇就只是另一篇公關稿。
規格改動是真的有代價。2026 年 7 月 28 日那一版拿掉了連線前的握手與連線識別碼，另外把 3 個原本內建的輔助功能列入淘汰窗口，舊的用戶端註冊方式也被標為將來會移除。依賴這些機制做出來的整合，需要評估並排定遷移；沒有踩到破壞性變更的整合未必要立刻動，但供應商該說得清楚自己屬於哪一種。
還有幾項批評，本文沒有能力用下載量或新版規格反駁。多接一層中介就多一個可能故障的環節。第三方寫的伺服器帶著供應鏈風險，公開市集上的擴充被稽核出多少比例帶著安全問題、行銷團隊沒有工程師時該用哪幾個問題當安裝門檻，站上另外整理過。把外部內容餵進模型引發的指令注入問題，換成命令列也一樣存在，換協定不會讓它消失。這些都還是開放問題。
本文的判斷是協定沒死，依據是採用軌跡與規格演進，不是說它已經沒有缺點。
這場爭論從頭到尾，沒有一方在吵資料對不對
把整場爭論的兩邊擺在一起看，會發現雙方隱含著同一個假設：不管走協定還是走命令列，代理讀到的資料本身是可信的。所有的火力都集中在門口該長什麼樣子，沒有一方在問門後面放的東西整不整齊。
對零售品牌來說，這兩件事的代價形狀不同。門口選錯，常見的代價是一次遷移工作外加一段時間的授權與資安風險，痛但有邊界。門後面的東西亂掉，代價是高風險決策持續被污染，而且沒有人會舉手告訴你它歪了。一個通道全開的代理，如果讀到的會員資料散在官網、門市、客服、廣告帳號各自的表裡，同一個人在 4 張表上是 4 個身分，它算出來的回購名單就是 4 份互相打架的名單。這一點我們在談代理購物時代的資料困局時反覆看到，換模型、換協定都不會讓它自己消失。
91APP CDMP 在這件事裡的位置，就是把散在各處的顧客資料收攏成同一個會員身分：線上線下的消費歸到同一個人身上，標籤與名單的定義只有一套，分群口徑跨團隊一致。上面接什麼載體都站得住，因為每一條通道讀到的是同一份事實。
這也是它相對抗跌的地方。會員與標籤的定義當然也會改，商業策略調整、法規變動都可能讓它需要重新盤點，所以它同樣需要版本管理。但比起一年動兩次的協定規格，這一層的節奏慢得多，而且改動由你自己決定、不是由別人的發布公告決定。你花 3 個月把歸戶規則跟標籤口徑談定，換幾次協定、換幾家廠商，那份定義都還在你手上。實務上的順序通常是先把歸戶與口徑收乾淨，再決定哪幾條資料開通道。若在口徑還沒對齊之前就大量接工具，常見的風險是不同工具讀到不同版本的會員數，什麼時候浮上檯面、影響多大，取決於資料同步與治理的現況。
至於伺服器該怎麼設計才不會把上下文吃光，為什麼一比一包裝要付出準確度、成本與資安三種代價，以及意圖導向的工具該怎麼組，站上有一篇專門處理，那個一鍵包裝的習慣正是這場爭論裡被罵得最凶、也最該改的一件事。
採購會議上該換掉的那個問句
以下幾件事不需要等預算，這個月就可以開始。共同點是它們都把問題從「這個協定會不會死」，換成「你要接的那個東西長什麼樣子」。技術題不必由行銷主管親自驗收，但問句要由懂業務的人提出來。
批評那種一鍵轉出幾十個工具的接法之後，正面的做法長什麼樣子也該講。想先自己動手試一支的話，不會寫程式的行銷人怎麼裝第一支 MCP server、各個安裝入口各自的前提與驗收方式，站上有一篇從頭走過一遍，那比在會議上空談協定生死有用得多。
- 把採購問句換掉。不要再問「你們支不支援 MCP」，改問「你們的伺服器對模型攤開幾個工具、有沒有做按需載入」。前一個問題所有廠商都會答有。後一個問題的標準答案是「有做按需載入，工具清單需要時才載入」，它的商業意義是這套東西掛著不用的時候不會一直產生費用（預期效果：只會展示、不願交代掛載成本的候選被提前排除；建議週期：寫進評選表，每次採購都問）。
- 把規格版本變成書面交付物，不要停在口頭回答。請供應商附上版本相容對照表、正式文件連結、可以試接的測試環境、舊版本停止支援的時程，以及遷移期間由誰負責。行銷側負責要求這幾份文件，實際驗收拉資訊或資安同仁一起（預期效果：把遷移風險從隱性變成合約條款；建議週期：簽約前一次問清，之後每年複查）。
- 資料口徑先固定，協定層晚一步再押。把會員歸戶規則、標籤定義、分群口徑談定並寫下來。明天就能做的第一步很小：挑出行銷最常用的 3 個名單，各自寫下它的定義與資料來源，看三個人寫出來的一不一樣（預期效果：換工具時只換管線不換定義；建議週期：第一週先做名單定義盤點，第一個月完成資料源清點）。
- 用一個窄場景，把成本問成錢而不是問成 token。挑一件像「查會員近期訂單並建議下一步溝通」的任務，請供應商提供這個情境的單次成本估算，並且分別報「掛滿工具」與「只掛這個任務用得到的工具」兩種情況（預期效果：拿到自己環境的預算數字，不必爭論別人量出來的百分比；建議週期：一個月試一個場景）。
換掉的是接法，留下來的是那份會員資料
回到那個夏天。技術社群量出了真實的成本，維護者把同樣的問題排進了路線圖，量測那篇的作者後來自己加註說問題已經大致被處理，兩邊都在做對的事，只有「已死」那兩個字是被放大出來的。
被宣告死亡的從來不是協定，是「把既有應用程式介面一鍵轉成幾十個工具、然後全部掛著」這種接法。那種接法正在被兩股力量修掉，一股是用戶端產品先改，一股是下一版規格的方向。
對台灣的零售品牌來說，這場爭論真正的用處，是它給了你一組更好的問題。廠商說支援某個協定，你可以再問一句怎麼接的；廠商說遷移不影響，你可以請他寫進合約。而在所有協定都還在互相取代的這段時間裡，你手上最不容易被別人的發布公告動搖的資產，仍然是那份只有一套口徑、對得起每一個真實的人的會員資料。
品牌最常問的 MCP 存廢問題
Q1：MCP 到底死了沒？
A1：沒有。它在 2026 年 7 月 28 日發布了問世以來最大的一次改版，官方同時揭露第一級開發套件每月下載接近 5 億次；2026 年 8 月 22 日更新的官方路線圖列了 5 個優先領域，有多個工作小組在推進。正在退場的是「把既有應用程式介面一鍵轉成幾十個工具、全部常駐掛著」這種接法，目前是靠用戶端產品先做按需載入，協定層的完整方案還列在路線圖上。
Q2：說它吃掉太多上下文，這個批評是不是真的？
A2：曾經是真的，現在要看你用哪一套工具。Quandri 的工程師估算 4 台伺服器合計 77 個工具，光工具定義就佔掉 20 萬 token 上下文視窗的 10.5%；Anthropic 自己也把「工具定義塞爆上下文視窗」列為兩個問題之一。但那篇原文後來加註，Claude Code 推出按需載入的工具搜尋之後，上下文用量下降超過 85%。這說明它是實作與載入策略的問題，不是協定注定如此。採購時該問的是你要接的那套工具有沒有做按需載入。
Q3：Agent Skills 出來之後，MCP 是不是就多餘了？
A3：不是。這兩套規格由同一家公司提出，Anthropic 在介紹 Agent Skills 的官方工程文章裡用的字是補足 MCP 伺服器。兩者回答的問題不同：MCP 處理代理讀不讀得到、動不動得了外部系統，Skills 處理拿到之後照什麼流程做。把它們當成二選一，通常會漏掉自己真正缺的那一塊。
Q4：那我們公司直接用命令列工具就好，不需要協定嗎？
A4：要看規模與權限怎麼管。命令列的主張在單一開發者的工作流裡站得住，前提是那個工具已經存在、而且登入問題已經解決。當使用者是幾十位行銷同事、有人離職那天要立刻收回權限、還要留下誰在什麼權限下取得了什麼的紀錄時，把長效金鑰寫在各自的設定檔裡就會變成治理負債。官方 2026 年 6 月 18 日發表的企業託管授權擴充，處理的正是這一段。
Q5：預算有限的中小品牌，現在該怎麼辦？
A5：先做不花錢的那一步。挑出最常用的 3 個名單，把定義與資料來源寫下來，看不同人寫出來的一不一樣。這一層不隨協定改版折舊。接下來評估工具時，把問句從「支不支援哪個協定」換成「你們的伺服器攤開幾個工具、有沒有按需載入」。
Q6：既然規格改這麼快，是不是該再等一等？
A6：等待本身也有成本，而且要區分等哪一層。協定層確實還在快速演進，2026 年 7 月 28 日那一版拿掉了連線前的握手與連線識別碼，也把 3 個內建輔助功能列入淘汰窗口，依賴這些機制的整合要排遷移。但資料底座那一層不受影響，而它通常才是專案真正的瓶頸。合理的做法是資料層現在就做，協定層先接一個窄場景驗證、把遷移責任寫進合約。