> ## Content Index > Fetch the complete content index at: https://growthhackers.tw/llms.txt > Use this file to discover other available public pages before exploring further. # MCP stateless 新規格解讀：MCP server 終於能上 serverless，但你的舊 connector 只剩 12 個月 - URL: https://growthhackers.tw/blog/mcp-stateless-core-spec/ - Published: 2026-07-30T05:00:00.000Z - Updated: 2026-07-30T05:00:00.000Z - Description: MCP 第五版規格上線，改成無狀態核心後，MCP server 終於能丟上 serverless。但通稿沒大聲講的是：initialize 握手、Session-Id、Roots、Sampling、Logging 全進了落日名單，只有 12 個月。 - Author: Lewis wang - Tags: MCP, AI agent, AI 工具, 電商經營, Anthropic 2026 年 7 月 28 日，Anthropic 在官方部落格宣布 [MCP 2026-07-28 規格](https://claude.com/blog/bringing-mcp-2026-07-28-to-claude?ref=growthhackers.tw)正式上線，這是 Model Context Protocol（模型上下文協定）的第五版規格。 官方同時放了幾個數字出來：MCP 的 SDK 月下載量超過 4 億次，今年成長 4 倍，Claude 的 connectors 目錄裡已經列出超過 950 個 MCP server。這些是 Anthropic 自己公布的數字，不是第三方稽核來的，不過量級大概夠說明一件事：MCP 正在變成 AI agent 接應用程式的產業標準。 但如果你問我，這版最重要的訊號，不在那些成長數字裡。 **重點是什麼？** 這是 MCP 第一次開始砍自己的舊東西。 initialize 握手流程，拿掉。Mcp-Session-Id（工作階段識別碼），拿掉。Roots、Sampling、Logging 這三個用了一年多的功能，加上舊的 HTTP+SSE 傳輸方式，全部進了落日名單，[MCP 官方發布公告](https://blog.modelcontextprotocol.io/posts/2026-07-28/?ref=growthhackers.tw)給的是 12 個月最短支援期。 一個協定願意訂淘汰時程，代表它不再是實驗品了。 ## MCP stateless core 到底改了什麼 MCP 是什麼、怎麼裝，我在 [GA4 MCP Server 安裝教學](https://growthhackers.tw/blog/ga4-mcp-server-install-tutorial-2026/)那篇寫過，這裡就不重複了。一句話帶過：它是讓 AI 直接接上你手邊工具跟資料的標準接頭。 這次的核心改動叫 stateless core（無狀態核心）。MCP 從「雙向有狀態協定」改成「請求／回應模型」。 簡單說，MCP stateless core 就是讓每次請求都自帶必要的上下文，不再依賴 server 端保存 session（工作階段）狀態。 聽起來很抽象，我用你每天都會遇到的場景講。 **以前的 MCP，像餐廳的訂位制。** 你走進去，服務生先幫你開一桌，記下你是誰、你點了什麼、你坐哪一桌。整頓飯下來，那張桌子一直是你的，服務生腦子裡一直存著你的資料。好處是他很懂你，缺點是那張桌子被佔住了，而且只有那位服務生記得你，他換班就麻煩了。 **現在的 MCP，像 7-11 的自助結帳機。** 你走過去，掃條碼、付錢、走人。機器不需要記得你是誰，因為你每次來都會自己把該講的資訊帶齊。所以尖峰時段店長要加開兩台機器，隨時可以加，客人隨便走哪一台都一樣。 ![有狀態像餐廳訂位制、無狀態像超商自助結帳的商業類比對照](https://growthhackers.tw/content/images/2026/07/inline-stateful-vs-stateless-v1.png) 技術上實際發生的事就是這樣：以前每個請求要靠工作階段識別碼綁在同一台伺服器上，現在協定版本、client 身分、能力宣告這些資訊，改成由每個請求自己帶著走，主要透過 `_meta` 跟新的 `Mcp-Method`、`Mcp-Name` 標頭完成。這也是為什麼閘道器不用拆開 JSON 就能決定怎麼路由。 差別在哪？以前你要架 MCP server，得養一台一直開著、記得住連線狀態的機器；現在它就是一支普通的 HTTP API，可以直接丟上 serverless 或 edge，前面擺個最陽春的負載平衡器輪流分配就行。 Netlify 的應用 AI 副總 Sean Roberts 在 Anthropic 的公告裡是這樣說的：「2026-07-28 規格裡的無狀態核心，讓 MCP 變成一等公民的 HTTP workload，沒有工作階段管理要繞過。」這句話講得很到位，不過要提醒你，這是合作廠商的背書發言，本來就帶宣傳性質。 我自己有感的是成本結構。我之前寫過[用 MCP 把 Google Ads 月報從兩週壓到兩分鐘](https://growthhackers.tw/blog/mcp-google-ads-workflow/)，那時候最卡的從來不是寫邏輯，是要顧一個一直開著的連線程序，它掛了整條流程就斷。這種東西你自己玩沒差，要變成公司每天在跑的工具，就是個維運負擔。 這道門檻現在降下來了。 對台灣中小型電商來說，這是第一次「自己接一個內部用的 connector」在帳面上划算。以前你評估下來大概是：要嘛養機器養人，要嘛乾脆等平台商做好。現在你把它當成一支普通的 API 部署，成本量級完全不同。 ## MCP 2026-07-28 spec 沒有大聲講的另外一半 官方公告的重點放在「建置變簡單」，這可以理解，畢竟那是好消息。 但你去翻 [MCP 官方的發布公告](https://blog.modelcontextprotocol.io/posts/2026-07-28/?ref=growthhackers.tw)，會看到另外一半故事：這版是刻意的一刀切（a clean break），不是溫和的疊加。 MCP 2026-07-28 規格中被 deprecated（淘汰）的項目包括： ► initialize / initialized 握手流程 ► Mcp-Session-Id 工作階段識別碼 ► Roots、Sampling、Logging 三個功能 ► 舊的 HTTP+SSE 傳輸方式 ► DCR（動態用戶端註冊）正式進入淘汰，未來由 CIMD（用戶端識別中繼資料文件）取代 TypeScript、Python、Go、C# 四大 SDK 都要更新，Rust SDK 還在 beta。 ![MCP 2026-07-28 規格的 12 個月落日名單與淘汰時間軸](https://growthhackers.tw/content/images/2026/07/inline-sunset-timeline-v1.png) **這件事台灣的行銷人其實剛經歷過一次。** 還記得 Universal Analytics 收掉、全部人被逼著搬去 GA4 那次嗎？Google 也是提前公告、也是給了緩衝期，結果呢？一大票公司拖到最後一個月才動，歷史資料沒搬完，報表斷層，然後年度檢討的時候發現去年同期的數字對不起來。 我當時看著身邊一堆同業在最後三個月同時發包，外包報價直接往上跳。 會踩坑的從來不是那些沒收到通知的人，是收到通知但覺得「還有一年，不急」的人。 MCP 這次給的也是 12 個月最短窗口。要講公道話，官方的建議其實很務實：無狀態這件事對新的 client 是立即生效的，但被淘汰的功能有緩衝期，不要在規格定案當天就把你 server 的 API 介面砍掉，跟著 SDK 的節奏遷移就好。 所以不用恐慌。但你得把它排進行事曆。 ## 還有一件事：IT 部門終於可以簽核了 這版還有一個改動，講的人不多，但對經營者來說可能最實際。 授權機制對齊了正式的 OAuth 2.0 與 OIDC，MCP server 可以直接接企業身分系統，像是 Microsoft Entra 或 Okta，不用再拿各種變通方法硬湊。Anthropic 那邊也上了企業託管授權，管理員透過身分提供者授權一次，全公司的人靠既有群組繼承權限，第一次登入就連上。 翻成白話：以前 MCP 是「工程師自己在電腦上裝的東西」，現在它可以變成「公司統一佈署、IT 管得到的資產」。 這個轉換點很關鍵。你在台灣稍微有規模的電商或零售公司待過就知道，一個工具能不能過資安跟稽核那關，決定它是永遠停在某個人的筆電裡，還是變成全公司的標配。能接 Okta，意思就是它終於可以被正式核准了。 這跟我之前寫 [Salesforce 把整個平台變成 AI agent 基礎設施](https://growthhackers.tw/blog/salesforce-platform-agent-infrastructure/)那篇看到的是同一件事的兩面：整個產業正在把 AI agent 從「試用階段」搬進「正式營運」，而搬家能不能成，關鍵不在模型多聰明，在身分、權限、稽核這些無聊東西有沒有做好。 這版還把 MCP Apps 跟 Tasks 正式收進版本化的擴充框架。MCP Apps 是讓 server 直接在對話裡長出互動介面，Tasks 則是處理跑很久的工作。 講具體一點，MCP Apps 的意思是：你的行銷助理問「上週哪支廣告最燒錢」，回來的可以是一張能點的圖表，不是一段要自己看的文字，也不用切到另一個分頁。Tasks 則是「幫我把三千筆商品描述重寫」這種要跑半小時的任務，可以丟著等它回報，不用開著視窗盯。 這兩個功能本身不新，新的是它們被收進了有版本號的正式框架。開發者以後要加功能有正規管道，不用去動核心協定。跟我上週寫 [Anthropic 的 Memory 與 Dreaming 兩個新原語](https://growthhackers.tw/blog/anthropic-agent-memory-dreaming/)時看到的是同一個動作：Anthropic 正在把 agent 這一整套東西模組化，讓每塊都能各自改版而不互相拖累。 有一點必須說清楚：Anthropic 官方的原文是 support is being rolled out（逐步推出中），不是全部到位。所以你現在看到的 Claude 產品線，功能是分批開的，別以為今天就能全用。 ## 那你現在該做什麼 如果你是經營者，不寫程式，這篇對你的意義就是五件事：前三件是明天就能問出口的問題，後兩件是節奏問題。 ![經營者該問 MCP 供應商的三個問題：接哪一版、何時遷移、誰付重寫的錢](https://growthhackers.tw/content/images/2026/07/inline-vendor-questions-v1.png) **► 第一，問你的供應商：「你們接的是哪一版 MCP 規格？」** 你買的電商平台、CDP、客服系統，只要文件上寫「支援 MCP」，就值得問這一句。答不出版本號的，通常代表那是行銷文案不是產品規格。 **► 第二，問：「遷移時程排在什麼時候？」** 12 個月看起來很久，但供應商的排程不等於你的排程。你要知道的是他們什麼時候動、會不會中斷服務、你這邊要不要配合測試。 **► 第三，問：「如果要重寫，誰付錢？」** 這題最現實。你如果去年外包做了一個內部用的 MCP connector，合約裡大概不會有「協定改版」這條。現在去釐清，比一年後吵架便宜。 **► 第四，如果你手上有自建的 connector，現在重新算一次帳。** 以前不划算的，用無狀態架構跟 serverless 重算一次，數字可能翻過來了。特別是那種「只有我們公司這樣做事」的內部流程，本來就沒有現成 SaaS 可買。 **► 第五，別急著全部重寫。** 跟著 SDK 的節奏走。官方自己都說不要在規格定案當天就砍舊介面，你更沒必要。先盤點、排期，不要因為看到「落日」兩個字就恐慌性發包，那正是 GA4 那次大家吃虧的方式。 ## 最後 Model Context Protocol 走到第五版，從一個 Anthropic 開源出來的接頭規格，長成官方宣稱 4 億月下載、connectors 目錄超過 950 個 MCP server、而且能接 Okta 跟 Entra 的東西。 這一版真正的分水嶺，是它從開發者的玩具，變成企業 IT 管得住的基礎設施。 而基礎設施跟玩具最大的差別，就是基礎設施有版本、有落日、有遷移成本。 好消息是門檻降了，你要自己接一個 connector 從來沒這麼便宜過。壞消息是時鐘開始走了，你不決定，時間會幫你決定。 如果你對 AI agent 怎麼被編排起來還沒概念，可以先看我寫的 [Agent Harness 是什麼](https://growthhackers.tw/blog/what-is-agent-harness/)，那篇會幫你把整張圖補齊。 分享給大家～ **資料來源**：[Anthropic 官方部落格：MCP 2026-07-28 spec: stateless core, coming to Claude](https://claude.com/blog/bringing-mcp-2026-07-28-to-claude?ref=growthhackers.tw)（2026 年 7 月 28 日發布）、[MCP 官方發布公告](https://blog.modelcontextprotocol.io/posts/2026-07-28/?ref=growthhackers.tw)、[MCP 2026-07-28 規格文件](https://modelcontextprotocol.io/specification/2026-07-28?ref=growthhackers.tw) --- **協作聲明與免責** 這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。 內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。