MCP 2026:Linux Foundation 接手後,協定狀態實戰報告
如果你在 2025 年初寫過 MCP 整合,那你今天重寫的版本,跟當時那個會是不一樣的東西。協定的核心沒變 — 還是有狀態的 JSON-RPC 連線,還是有 resources、tools、prompts、sampling、roots、elicitation — 但圍繞它的東西全部動過了:治理、發佈方式、認證,甚至連伺服器可以渲染什麼 UI 都重新定義。如果你還把 MCP 當成新玩意兒在觀望,這個時候繼續觀望會開始變貴。
接下來是 2026 年中的真實狀況:MCP 走到哪裡、還在動的地方有哪些、現在值得投入工程時間的是什麼。這篇不是教學 — 那種文章外面一大堆,品質大多還行。這篇比較像田野筆記。
三分鐘重看一次架構
MCP 還是 host(LLM 應用)、client(host 內的連接器)、server(工具或資料提供者)三層,跑 JSON-RPC 2.0。Host 掌握同意權。Server 暴露三個核心 primitive — resources(模型可以讀的檔案型資料)、tools(模型可以呼叫的函式)、prompts(範本化的工作流程);加上三個 client-side primitive 給 server 反過來呼叫:sampling(遞迴 LLM 呼叫)、roots(檔案系統邊界)、elicitation(向使用者要輸入)。
現在不一樣的有兩件事。第一,目前的 spec 版本是 2025-06-18 — 這是 client 和 server 在 handshake 時協商的協定版本。如果你還綁在 2024-11 那版,client 和 server 之間會默默失去一些能力。第二,官方 SDK 現在有九種:TypeScript、Python、Java、Kotlin、Swift、C#、Go、PHP、Rust。2026 年初推出的 SDK tiering 系統會依功能完整性分級,所以你不用再靠猜的選語言 — 看你需要哪些 extension 來挑就好。
SDK tiering 實際運作方式
Tier 1 SDK(目前是 TypeScript 和 Python)必須支援每個核心協定特性、每個已經從 experimental 升級的官方 extension,並且要附相容性 release notes。Tier 2 SDK(Java、C#、Go、Swift、Kotlin、Rust)涵蓋核心跟大部分 extension,但會有時間差。Tier 3(PHP 加上社群維護的 port)只有核心,有時候 “tier 3” 是一種禮貌的說法,意思是“這個 SDK 拿來讀資料沒問題,但不要把 production 押在它上面”。實際挑法是列出你打算用的 extension,然後查 SDK 公開的 coverage matrix。跳過這步,就是團隊寫到一半才發現某個 extension 方法在你選的語言裡根本不存在的標準路徑。
2025 年底以來,真正有感的五個改變
1. 治理搬到 Linux Foundation
MCP 是 Anthropic 在 2024 年底推出的。到了 2026 年第一季,整個專案轉到 Linux Foundation 旗下,由多家廠商共同治理,有正式的 Working Group 和 Interest Group、有公開的治理章程,還有明定的 contributor ladder,從第一次 commit 一路寫到 core maintainer 該具備什麼條件。Steering group 不再是單一公司。
對開發者來說,這改變兩件事。你不再需要押注某家廠商的 roadmap — extension 提案走 SEP(Specification Enhancement Proposal)流程,要有 working group 背書。還有,如果你今天做了一個 server,可以透過官方審核流程發佈到 Registry,不用靠 GitHub 點星數碰運氣。
SEP 流程,用一段講完
如果你看過一個關鍵的協定功能因為某家廠商跟另一家廠商意見不合而卡住,SEP 流程就是設計來避免這種事。一份 SEP 是寫成文件的提案,內含動機、設計、和參考實作。它先送到相關的 Working Group;如果 WG 接受,SEP 進入 Core Maintainer 審查。Core Maintainer 對是否納入核心 spec 或成為官方 extension 有最終決定權。Extension-track 的 SEP 走同樣的流程,但會升級為“官方 extension”而不是核心特性。這樣的分離重要,因為它讓 spec 在核心層保守演進、在邊緣層積極擴展。
實際上代表:如果協定不支援你想做的東西,你有正式的路徑提案。Working Group 有公開的章程、季度審查、和 contributor ladder,讓投入的社群成員可以成為 maintainer。參與的技術門檻是“能寫一份帶程式碼範例的設計文件”,不是“在 Anthropic 工作”。
2. MCP Registry 上線
位於 registry.modelcontextprotocol.io 的官方 MCP Registry在 2025 年底上線,目前已經索引了發佈出去的 MCP server,包含版本歷史、套件中繼資料、發佈者身份認證。還有一些獨立的 registry aggregator 從多個來源彙整,加上自己的策展邏輯。
實際效果:發現工具不用再 Google。寫 client 的時候,你可以直接從 registry 拉清單,不用叫使用者貼 JSON 設定。發佈 server 的時候,可以走正式管道,不用自己行銷。發佈流程綁 GitHub 認證加上審核機制 — 這是對的取捨,完全開放會讓 registry 變成惡意程式 buffet。Aggregator 的故事也有意思:第三方 registry 可以在官方之上疊加信任訊號,讓企業可以發佈私有索引,不必為了這個去 fork spec。
3. 認證正式走 OAuth 2.1
2025 年大部分時間,MCP server 不是跑在本機 STDIO、用環境變數帶認證,就是自己土砲一個認證層掛在 transport 上。這條路現在不再是推薦做法。新的授權教學文件走的是 RFC 對齊的 OAuth 2.1 流程,用 Protected Resource Metadata(RFC 9728),搭配 pre-registration 或 Dynamic Client Registration。
Wire-level 的改變:MCP server 現在會回 401,在 WWW-Authenticate header 裡指給 client 一份 .well-known/oauth-protected-resource 文件。Client 拿到授權伺服器資訊後註冊自己、走標準的 authorization-code-with-PKCE 流程、拿 bearer token 回來。Server 那一端可以直接接 Keycloak、Auth0、Okta,或任何 RFC 8414 / OIDC 相容的 IdP。
4. MCP Apps:在對話裡渲染 UI
MCP Apps 這個 extension(目前還是 experimental,但已經有真實的 host 支援)讓 server 在工具結果旁邊回傳渲染過的 UI — 圖表、表單、影片播放器、嵌入式 canvas。Client 在 initialize 請求的 io.modelcontextprotocol/ui 擴充能力裡宣告支援,通常是 text/html;profile=mcp-app。Server 在 initialize 回應裡也宣告同一個 extension 就完成協商。
最值得講的設計選擇是 graceful degradation。支援 UI 的 server 對不支援的 client 還是要回有意義的文字內容,這樣才不會把舊版 host 弄壞。這是對的決定 — 最糟的結果會是一整波只能在某一個 client 跑的 server。
5. Tasks:不必再為長任務掛著連線
MCP Tasks extension 解決每個 production team 都撞過的問題:有些 tool 呼叫要跑好幾分鐘(CI pipeline、批次工作、人工審核),這麼久掛著一條連線不實際。Tasks 讓 server 改回一個持久的 task handle,而不是同步結果。Client 用 tasks/get 輪詢,或訂閱 notifications/tasks 接收推播。
最乾淨的細節:task 可以轉成 input_required 狀態,這時候 server 會在 tasks/get 回應裡帶 elicitation 請求。Client 用 tasks/update 回應。這就是大家以前自己用另一組 HTTP endpoint 手刻的 human-in-the-loop 模式,現在協定層做對了。
2026 年中,transport 怎麼選
MCP 現在支援兩種 transport,選擇比大多數部落格文章承認的更重要。
| Transport | 適合場景 | 取捨 |
|---|---|---|
| STDIO | 本機開發、單機桌面 app、任何把 server 跑成 host 子進程的場景。 | 簡單。不需要認證,因為作業系統處理行程隔離。Log 一律走 stderr,絕對不能走 stdout — print 會把 JSON-RPC 訊框弄壞。無法支援多使用者。 |
| Streamable HTTP | 遠端 server、多使用者部署、任何在 load balancer 後面的服務。 | 設定正確的話可以走 stateless。支援 OAuth 2.1。可以用標準 HTTP 基礎設施。如果要做 server 重啟後的 session 復原要小心處理 — 這在 Transport WG 的 roadmap 上,目前還沒完整解決。 |
團隊一直在犯的錯就是把 STDIO server 部署到 production。STDIO server 預設它擁有 host 的整個檔案系統、環境變數、和信任。當你把它包進 container 然後說“這是 production”的時候,你只是用多餘的步驟做出一個 confused deputy 漏洞。如果你的 server 要服務超過一個人,你需要 Streamable HTTP,而且從第一天就要想認證。
把授權模型講白話一點
OAuth 2.1 教學讀起來比實際複雜。流程是這樣:
- Client 連線。Server 回
401並在 WWW-Authenticate header 裡指到 Protected Resource Metadata(PRM)文件。 - Client 抓 PRM,看哪些授權伺服器和 scope 是合法的。
- Client 註冊自己(pre-registered 或 Dynamic Client Registration)。
- Client 開瀏覽器到
/authorize,使用者登入、拿到 authorization code。 - Client 用 code 換 token,把 bearer token 帶在 MCP 請求上。
痛點在第三步。如果你的 IdP 不支援 Dynamic Client Registration,client 也沒預先註冊,你就會掉進人工輸入的 fallback — 而“人工輸入”這種 UX 最後會變成使用者把 client secret 貼到 Discord 裡。企業部署這就是為什麼會有 Enterprise-Managed Authorization extension:讓 IT 預先註冊 client、走和其他系統一樣的 SSO。
OAuth Client Credentials extension 處理另一半的問題 — 沒有人類在迴圈裡的機器對機器流程。如果你的 MCP server 是後端服務呼叫其他後端,你要這個 extension,而不是 user-facing 的 authorization code 流程。
OAuth 2.1 spec 對你真正的要求
對 server 作者,容易忽略的是:驗證傳入 token 的 resource claim,確保一張發給 A 伺服器的 token 不能被重放到 B 伺服器(spec 稱之為 audience 檢查,跳過它的後果不是理論上的)。所有 authorization-code 流程都要用 PKCE,包括 confidential client — 對“信任的” first-party client 省略它,就是 mix-up attack 發生的方式。把 token introspection 和 revocation 當一級議題處理:如果你的 server 會 cache token,就要有 revocation hook,讓被洩漏的 token 不會繼續有效一小時。
對 client 作者,對等的不顯眼細節:不要盲目相信 token 的 scope claim — 從 server 的 PRM 文件重新推導 scope。遇到 401 要做 token refresh,不是硬重連。每次授權嘗試都要 log 使用者、client、請求的 scope 和時間戳。Audit trail 是區分業餘 MCP 部署和撐得過企業資安審查的差別。
自己寫 vs 直接裝:什麼時候該自建 server
現在市面上有幾千個 MCP server。自寫的判斷落在三個情境:
- 整合對象在內部。如果你需要一個能跟你自家資料庫、內部 CI、或專有 API 對接的 server,registry 沒人能幫你。自己寫、自己保護、放在自己的基礎設施上。
- 現成的 server 沒人維護。很多 2025 年初冒出來的社群 server 從那之後就沒更新。如果一個 server 的最後一次 commit 在 2025-06-18 spec 修訂之前,當作棄置專案處理,規劃 fork 或換掉。
- 你需要一個還沒被廣泛支援的 extension。如果你要客製 elicitation 流程的 Tasks,或特定 MIME profile 的 MCP Apps,你要寫的程式碼會比能抄的多。自寫。
其他情境,裝就好。官方 Registry 有審核機制擋掉最惡意的內容。獨立 aggregator 給你廣度。省下來的時間拿去寫你真正的產品。
什麼時候 MCP 不是對的工具
MCP 不是萬靈丹,裝成萬靈丹會弄出壞架構。
整合只是一個模型的一次函式呼叫的時候,跳過 MCP。如果你的 chatbot 只需要一個 tool,一個 HTTP endpoint 加 function-calling schema 比 MCP server 的基礎設施成本低。MCP 的複雜度要在多個 tool、有共享狀態、或有長期 host-client 關係時才划算。
延遲敏感的時候,跳過 MCP。每一次 MCP 呼叫都要加上 JSON-RPC 框架、能力協商,HTTP 還要再多一個完整 round-trip。對延遲預算很緊的場景,inline 函式呼叫會贏。
整個 stack 都是你的時候,跳過 MCP。如果同一個團隊同時擁有模型、工具、和 UI,MCP 是 overhead。它存在是為了解決跨廠商互通 — 如果根本沒有跨廠商,你在為不需要的彈性付費。
Production 上常見的坑
這幾個是實際部署會遇到的問題,不是 spec 文件裡那種。
Log 打到 stdout
如果你的 STDIO server 印任何東西到 stdout,JSON-RPC stream 就壞了,client 會看到垃圾。用 stderr 或 logging library。官方教學有提醒,但每個團隊都還是會撞一次。
信任來路不明的 server 的 tool 描述
Spec 講得很清楚:tool 描述不可信,除非 server 是你驗證過的。惡意 server 可以在 tool 描述裡塞 prompt injection payload。Host 應該把描述顯示給使用者看,而不是給模型,讓使用者自己決定要授權什麼。
忘了指定協定版本
在 initialize handshake 把 protocolVersion 寫死。如果你沒寫,你會拿到 server 的預設值,可能比你 client 支援的還舊。這個失敗是靜默的 — 不會 crash,只會少一些能力。
同一個 session 中途換 transport
Session 綁 transport。如果你從 STDIO 開始,然後試圖用同一個 session ID 換到 HTTP 重連,會出事。把 transport 選擇當部署決策,不是 runtime fallback。
用長連線跑長時間同步任務
如果你開始想為了十分鐘的 CI 執行把一條 TCP 連線掛在那邊,你需要 Tasks。如果你因為“比較簡單”而不想用,你會因為網路 timeout、container 重啟、OAuth token 過期而掉工作。用 extension。
跳過 initialize handshake 驗證
Handshake 是協商能力的地方。如果你的 client 沒檢查 server 宣告的能力,你會在執行階段才發現你預期的 tool 不存在 — 通常是在 demo 的時候。每次都要驗證 server 宣告的能力跟你 client 程式碼預期的 tool、resource、extension 是否對得上。
沒有版本管理策略
Server 會演進。Tool 會被改名、參數會改、prompt 會重寫。如果你的 client 在 server 每次出新的 minor 版時就壞掉,你做的不是 MCP 整合 — 你做的是多了幾個步驟的耦合問題。好好用 semver:破壞性 tool 簽章改動跳 major,新增跳 minor,bugfix 跳 patch。MCP Registry 索引版本,尊重版本 pin 的 client 會感謝你。
實戰決策檢查清單
- 單機、本機 app? STDIO,不認證,認證放環境變數。
- 多使用者 SaaS? Streamable HTTP,OAuth 2.1,接 Keycloak 或你現有的 IdP。
- Server 對 server、沒有人類? Streamable HTTP,OAuth Client Credentials extension。
- 長時間任務? Tasks extension,有需要人工批准的步驟就加
input_required。 - 要渲染 UI? MCP Apps extension,宣告
text/html;profile=mcp-app,永遠保留文字 fallback。 - 企業 IT 要介入? Enterprise-Managed Authorization extension,預先註冊 client,走 SSO。
- 要發佈 server? 推到官方 Registry,不要只放 GitHub release。
- 選 SDK? 看 SDK tiering 文件 — TypeScript 和 Python 是 tier 1,其他依 extension 支援度有差。
常見問題
用 Streamable HTTP 之後還需要自己寫認證層嗎?
如果 server 有任何使用者特定的資料,要。STDIO 加環境變數對單機本機使用者沒問題,但遠端 server 一旦碰到使用者資料,就需要 OAuth 2.1 加 PRM discovery。自己土砲認證是 spec 所說的“strongly discouraged”— 用現成的 IdP 跑標準流程。
MCP Apps 和從 tool 直接回 HTML 有什麼差別?
Tool 回的是文字或結構化內容。MCP Apps 回的是在 host 內部沙箱 iframe 裡渲染的 UI,有明確的生命週期事件,讓 host 知道什麼時候要把 UI 收掉。如果從 tool 直接回 raw HTML,host 會選擇忽略,或用不安全的方式渲染。用 extension。
Tasks 跟 Celery / Temporal / job queue 一樣嗎?
不一樣。Tasks 是協定層的模式 — server 回 handle,client 輪詢。如果你需要 durable、可重試、多步驟的編排,你還是要 Temporal 或 job queue 在 server 內部。Tasks 解決的是 MCP client 和 server 間長任務的 wire-level 問題。
要等協定穩定才動手嗎?
如果你是做內部工具,你已經等太久了。核心 spec 是穩定的,SDK 是 production-grade,extension 是附加的 — opt-in,並且有 graceful degradation。如果你要做一個要活五年的東西,把 protocol version 寫死,設計時考慮 extension capability negotiation,就能在 extension 穩定時逐步採用。
為什麼治理要搬到 Linux Foundation?
因為多廠商採用需要多廠商治理。一個定義所有 AI agent 跟所有工具怎麼對話的協定,不能由一家公司主導 — 沒有中立的家,廠商不會 commit。Linux Foundation 的搬遷,是後續企業投資和 SDK 投資的前置條件。
這週可以做的事
如果你已經有 MCP 整合,拿 2025-06-18 spec 修訂和你 SDK 的 tier 等級做一次 audit。如果你剛起步,先做最小可行版本 — 一個 tool、STDIO transport、不認證 — 等到使用情境需要時再加 Streamable HTTP、OAuth 2.1、或 Tasks。
MCP 已經不是當初推出時那個“USB-C for AI”的比喻。它是愈來愈多 agentic 產品底層的工作底材。協定走到今天,是靠變得更無聊 — 更多 spec、更多治理、更少意外。這是對的那種進步,也是對的那個開始動手的時機。
未來六個月值得追的事
Roadmap 是公開的,這本身就是成熟的跡象。2026 年底之前有三件事有相當高的機會落地:
- Stateless Streamable HTTP 加上完整的 session migration。Transport WG 正在完成 SEP,目標是讓 wire format 在 load balancer 和 server 重啟下都能正確運作。如果你今天大規模部署 MCP server,你還在做人工 session-stickiness 的 hack。這部分會變乾淨。
- Server Cards。一份標準化的中繼資料文件,放在
.well-knownURL,描述一個 server 做什麼、不需要實際連線。這會在沒辦法做 live handshake 的地方解鎖發現能力 — 搜尋引擎、agent marketplace、企業型錄。 - Triggers 和 events。現在 client 透過輪詢或掛著 SSE 連線來知道 server 端的變化。標準化的 webhook 式通知機制會讓 server 可以推播更新,而不必佔用 client 連線。WG charter 已經有了,SEP 在審查中。
還在比較遠的:streamed 和 reference-based 的 tool 結果(讓 200MB 的 tool 回應不用塞進一個 JSON-RPC 訊框)、DPoP for sender-constrained token、Workload Identity Federation 讓你的 CI 不用靜態認證就能呼叫 MCP server。這些都不是等的理由,但都是持續關注 roadmap 的理由。