這次 MCP 規格更新,跟一般使用者有什麼關係?我又不是開發者。
如果你只是在 Claude 裡連接既有的 MCP 連接器(例如 Google Drive、Notion 這類),這次更新對你來說是「幕後」的改變——你不需要自己重新設定什麼,連接器背後的服務提供商會負責遷移到新規格。但你會間接感受到兩個影響:第一,MCP Apps 這個功能,讓部分連接器可以直接在對話視窗裡顯示互動介面,不用切換分頁確認狀態,這是可以直接感受到的體驗改善;第二,無狀態化讓伺服器更容易擴展,長期而言代表連接器在高流量時比較不容易出現連線不穩的狀況。
如果你的組織是企業用戶,而且管理員有開通「企業託管驗證」,你可能會發現以後新的 MCP 連接器不需要自己個別登入授權,登入公司帳號後就自動取得存取權——這是規格更新後,Claude 端新增功能帶來的直接體驗差異。
MCP 為什麼需要改成無狀態架構,原本的雙向長連線設計有什麼問題?
原本 MCP 採用雙向、需要維持連線狀態的協議設計,這代表每個 MCP 伺服器都必須自己處理連線管理、意外斷線後的重連邏輯,這對開發單一連接器的團隊而言是額外的架構負擔,對想擴大規模服務更多使用者的團隊而言,問題更明顯——維持大量長連線本身就需要相應的伺服器資源與架構複雜度。
改成無狀態的請求-回應模型後,MCP 伺服器可以直接部署在無伺服器(serverless)與邊緣運算這類基礎設施上——這類架構的特性正是「不需要維持長連線」,原本雙向協議設計反而讓 MCP 伺服器無法直接享受這類基礎設施帶來的擴展彈性。這也是為什麼 Netlify 的工程副總裁會形容,無狀態核心讓 MCP 變成「一等公民的 HTTP 工作負載」——意思是它終於能像一般的 HTTP API 一樣,直接套用整個產業已經很成熟的擴展方案,不需要為了維持連線狀態,額外設計一套專屬的架構。
MCP Apps 跟 Tasks 這兩個能力,實際運作起來是什麼樣子?
MCP Apps 解決的是「連接器在做事,但使用者看不到過程」的問題——過去如果 MCP 連接器在背景執行一個比較複雜的操作,使用者往往要切換到該服務的原生介面才能確認進度或結果。有了 MCP Apps 之後,伺服器可以直接把互動介面渲染在 Claude 的對話視窗裡,使用者不需要離開對話,就能看到連接器實際在做什麼、甚至直接在介面裡操作。
Tasks 則是處理另一個常見痛點:有些工作本來就需要執行一段時間(例如產生一份報告、跑一個較長的資料處理流程),如果協議沒有正式的機制來表達「這個工作還在進行中」,開發者往往要自己想辦法(例如讓連接器持續回傳空白狀態,或是要求使用者手動重新查詢)。Tasks 為這類長時間執行的工作提供了正式的處理路徑,讓「工作還在進行」變成協議層級就能表達的狀態,而不是每個開發者各自發明一套權宜做法。
這次更新把這兩者收進「版本化擴充框架」,而不是直接寫進協議核心,代表的意義是:未來如果還要新增類似的能力,可以在這個框架裡加版本、加擴充,不需要每次都改動 MCP 協議本身的核心規格,對整個生態系的相容性跟穩定性是比較健康的做法。
如果我是開發者,考慮建立自己的 MCP 伺服器,這次更新對我來說最實際的影響是什麼?
最直接的影響是部署成本跟複雜度下降——無狀態化之後,你可以直接把 MCP 伺服器部署在 serverless 或邊緣運算平台上,不需要另外設計連線管理與重連邏輯,這代表從零開始建立一個 MCP 伺服器的門檻明顯降低,也不需要為了維持長連線而預留固定的伺服器資源。
如果你的目標使用者包含企業客戶,身分驗證的強化也值得注意——現在可以直接對齊 OAuth 2.0 與 OIDC 的正式環境部署方式,連接企業既有的身分系統(如 Entra、Okta)不需要寫變通方案,這降低了企業客戶導入你的連接器時的整合成本。
實務上要留意的是,如果你已經有一個運行中的 MCP 伺服器,規格更新不代表你需要立刻遷移——公告裡提到既有的 beta 整合會持續運作,遷移是漸進式的過程,建議先查閱官方規格文件跟 SDK,確認自己使用的框架是否已經支援新規格,再規劃遷移時程,而不是急著一次性改版。
MCP(Model Context Protocol)在 2026 年 7 月 28 日迎來至今最重要的一次規格更新。這不是一次外觀上的調整,而是動到協議底層架構的改版——如果你平常會連接 MCP 伺服器,或考慮自己架一個,這次更新直接影響「怎麼架設」「能不能撐得住流量」這些實際問題。
最核心的改變,是 MCP 從雙向、需要維持連線狀態的協議,轉變成無狀態的請求-回應模型。過去 MCP 伺服器需要維持一條持續開啟的連線來處理狀態,這代表伺服器架構必須考慮連線管理、重連機制等額外複雜度;無狀態化之後,MCP 伺服器可以直接部署在無伺服器(serverless)與邊緣運算基礎設施上,不需要維護長連線,對開發者而言,建置與擴展 MCP 伺服器的複雜度明顯降低。
這個改變的實際意義,體現在多家已經在新規格上開發的公司回饋裡。Netlify 應用 AI 副總裁 Sean Roberts 提到,無狀態核心讓 MCP 成為一等公民的 HTTP 工作負載,不再需要額外處理 session 管理;Zapier 的產品工程師 Paul D'Ambra 也表示,協議轉向無狀態,讓擴展自家服務、以及為客戶的 MCP 伺服器新增用量分析都變得更容易。
第二個重要變化,是 MCP Apps 與 Tasks 這兩個能力,正式收進一套版本化的擴充框架裡。MCP Apps 讓伺服器可以直接在對話裡渲染互動式介面,使用者能直接在對話視窗內操作連接器在做的事,不需要切換分頁確認狀態;Tasks 則是為長時間執行的工作提供正式的處理路徑。把這兩者收進獨立的擴充框架,代表未來新增類似能力時,不需要每次都修改協議核心本身,對整個生態系的長期穩定性是正面訊號。
第三個變化是授權機制的強化——這次更新讓 MCP 的身分驗證直接對齊正式環境常用的 OAuth 2.0 與 OIDC 部署方式,代表 MCP 伺服器可以無痛接上企業既有的身分系統,例如 Microsoft Entra 或 Okta,不需要額外寫變通方案。對企業使用者而言,這跟 Claude 目前提供的「企業託管驗證」(Enterprise-managed auth)是互補的——管理員可以透過既有的身分供應商,一次性授權一個連接器給整個組織使用,使用者第一次登入時就自動取得存取權限,不需要逐一設定。
除了協議本身的變動,Anthropic 也同步為 Claude 加上幾項搭配新規格的功能:MCP Apps 讓連接器可以直接在對話裡顯示互動介面;企業託管驗證讓管理員能一次性設定,使用者透過既有身分系統就能自動取得存取權;針對開發者,新增了可觀測性儀表板,可以追蹤自己發布的連接器在 Claude 各個介面上的採用率、錯誤率與延遲;MCP tunnels(目前為研究預覽階段)則讓 Claude 能連到私有網路內的 MCP 伺服器,不需要對外開放連接埠或設定 IP 白名單。截至這次公告,Claude 的連接器目錄已收錄超過 950 個 MCP 伺服器,每天有數百萬人在使用。