MCP

MCP 有發布日曆了：SEP-3398、Server Cards 與十月安全浪潮對 B2B 代理部署意味著什麼

作者：IdeaBosque最後更新：2026年10月31日

核心重點

MCP 規範現在按固定日曆發布 — SEP-3398 於 2026 年 10 月 14 日獲得通過，設定每六個月發布一次，時間為三月的最後一個週二與九月的最後一個週二，並將 2026 年 12 月的目標延後至 2027 年 3 月下旬。
Server Cards 已成為正式標準 — SEP-2127 於 2026 年 10 月 6 日合併為 Final，為 MCP 伺服器提供了標準化的元數據文件，可在建立連線之前得知傳輸方式、協定版本與連接指引。
官方儲存庫在 28 天內發布 31 份安全公告 — 據 eSEOspace 的 State of MCP October，其中包括 MCP Inspector 的兩份嚴重級，已在 10 月 21 日的 1.0.3 安全版本中修復。
Smithery 代理與託管身份服務於 2026 年 10 月 31 日關停 — Smithery 自己的通知將 run.tools 與 server.smithery.ai 的伺服器 URL 退役——這是本月對「租用分發路由即維運風險」最清晰的證明。
按 2026-07-28 規範規劃整個冬季 — 無狀態核心不受影響；下一版本將於 2027 年 3 月下旬發布，遷移節奏可以寫進日曆，而不是被動追趕 changelog。

Smithery 的 MCP 代理與託管身份服務於 2026 年 10 月 31 日——今天——關停。仍透過 run.tools 或 server.smithery.ai 的 URL 解析伺服器的代理部署隨之中斷；Smithery 自己的通知列出了失去的一切：託管伺服器 URL、API、Connect 與 Toolbox、帳戶、API key 以及 CLI。遷移方案落在供應商自己的端點——用 mcp.linear.app/mcp 取代 linear.run.tools——而從來沒有自建遷移清單的團隊，只能在今天現寫一個。

同樣在這 28 天裡，MCP 的維護者通過了該協定的首個固定發布日曆、將 Server Cards 發現標準合併為 Final，並且——按 eSEOspace 的統計——在官方 MCP 儲存庫記錄了 31 份安全公告，其中兩份在 MCP Inspector 被評為嚴重級。

這個組合是從三個方向看到的同一場轉型——日程、發現與維運。MCP 已不再像快速迭代的膠水層，而開始像託管的基礎設施。本文把十月的紀錄當作一個訊號來解讀，並給出它所要求的維運節奏：鎖定規範版本，把發布節點寫進日曆，讓 SDK 停留在安全發布軌道上，並且不再租用分發路由。

本文是 MCP 2026-07-28：無狀態協定對 B2B 代理部署的意義的續篇——那篇涵蓋了無狀態核心、顯式句柄模式與 7 月 28 日規範的部署帳算。這裡聚焦的是十月圍繞那份規範發生的變化：發布節奏、發現層、公告流與分發停服。無狀態論點本身未被其中任何一項觸及。

十月紀錄一覽

圖註：28 天內的五個事件，把 MCP 從一份滾動的規範變成一個帶日曆、帶發現標準、帶安全發布軌道、並經歷首次第三方分發中斷的平台。

一個被接受、隨後完成的發布日曆

SEP-3398 是一份流程類 SEP，流程類 SEP 很少登上頭條——但這一份應該上。10 月 14 日獲得通過、10 月 27 日完成合併，它把 MCP 的發布節奏寫進文本：規範每六個月發布一次，「通常是三月的最後一個週二與九月的最後一個週二」，每個版本有八個月的工作週期——兩個月規劃、一個排定的核心維護者（Core Maintainer）審查窗口、一個穩定階段——相鄰兩個週期相互重疊兩個月。過渡條款補齊其餘：原定的 2026 年 12 月發布目標延後到 2027 年 3 月下旬。

對維護者而言，這是審查容量的管理。對 B2B 部署而言，這是規劃基礎設施：

棄用窗口現在可以放進日曆。 Roots、Sampling、Logging 與已棄用的 HTTP+SSE 傳輸自 7 月 28 日規範起就帶著 12 個月的僅註解窗口。固定日曆把「從 7 月 28 日起 12 個月」變成與 ERP 發布窗口同處一張路線圖的節點。
未完成的工作順延，日期不動。 與發布綁定的提案必須在 soft freeze 前達到 Final 並完成合併；未完成的提案順延到之後的週期，發布日期不變。這正是團隊對平台供應商的期待——可預測性優先於完整性。

最直接的實務結論來自 eSEOspace 對十月數據的解讀：十月沒有任何新規範版本發布——最新版本仍是 2026-07-28，日曆把下一版本推到 2027 年 3 月下旬。今天部署所鎖定錨定的無狀態核心，整個冬季都仍然有效。

Server Cards：發現不再是一個配置檔

SEP-2127（MCP Server Cards）於 10 月 6 日合併為 Final——早於日曆 SEP——補上了部署問題的另一半。無狀態規範定義了代理在連線之後如何與伺服器通訊。Server Cards 定義代理如何在無需手工設定的情況下找到伺服器：一份標準化的元數據文件，描述傳輸方式、協定版本與連接指引，由伺服器暴露、由用戶端在任何連線建立之前讀取。

來自 SEP 本身的機制：每台伺服器暴露自己的 card——card 可託管於任意未保留的 URI，建議位置是 <streamable-http-url>/server-card——掛載於擴充功能識別碼 io.modelcontextprotocol/server-card 之下。網域級「AI Catalog」可以連結或嵌入相關 card，這正是註冊表爬取與服務自動發現無需逐個端點手工處理的原因。

B2B 的對應物是 A2A 的 agent card——.well-known/agent-card.json——我們對 A2A 的覆蓋已把它視為機器間發現的基礎配置。Server Card 是協定伺服器的同一思路，它刪除了多數代理部署今天維護的製件：手寫的伺服器端點及其工具 schema 清單。當這份清單變成可發現的元數據，維運姿態在三個方面改變——新伺服器自動宣告自己的表面；失效端點變得可稽核（與線上伺服器不再匹配的 card 本身就是發現項）；供應商升級不再需要用戶端側的重新設定。

SDK 與用戶端支援是 SEP 聲明的下一步，所以務實的做法是現在就按此設計：建置端點時預留 card 位置，並讓伺服器清單隨時可以變成元數據而不是設定。

十月安全浪潮：公告成為維運節奏的一部分

十月紀錄中最鋒利的行是安全行，讀起來更像平台供應商的補丁日，而非業餘專案的 changelog。MCP Inspector 的兩份嚴重級於 10 月 21 日發布，均在 1.0.3 安全版本中修復：

GHSA-6x67-4w4w-9f3w — 遠端 MCP App 可竊取代理的認證權杖並執行任意本機命令（RCE）。受影響版本：Inspector 0.20.0 至 1.0.2。
GHSA-4fc4-wcmh-4g86 — 惡意 MCP OAuth 回呼可把傳輸切換到 stdio 並執行任意本機命令（RCE）。受影響版本：0.13.0 至 1.0.2。

Inspector 之外，TypeScript SDK 的十月公告是對 B2B 最有殺傷力的一條：GHSA-jm63-cq47-j5jp——「共享傳輸或伺服器實例把一個 HTTP 用戶端的訊息發給了另一個」——評級為高，自 2.0.0 起受影響，在 2.3.0 修復。共享傳輸導致的跨用戶端資料外洩，恰是 B2B 部署無法容忍的缺陷類別，而它落在 SDK 的核心套件裡，不是實驗性角落。

發布日期與嚴重程度同樣清晰地講述平台故事。Python SDK 2.3.0 於 10 月 2 日發布，在工具註冊時收緊標頭檢查；TypeScript SDK 2.4.0 於 10 月 23 日發布，加入 Skills-over-MCP（SEP-2640）支援；Kotlin 0.16.0 於 10 月 27 日發布，封堵記憶體耗盡漏洞並棄用 SSE（發布說明；定性依據 eSEOspace 的發布說明審查）。四個主要的官方 SDK 在本月都至少發布了一次，而按 eSEOspace 的審查，貫穿其中的主題是加固：請求大小、工作階段數量與記憶體的硬性限制。他們對官方儲存庫公告數的統計——28 天 31 份——是他們自己的口徑，但它描述的形態可以核驗：安全發布軌道如今是連續的，不是間歇的。

對維運者的解讀很簡單。如果你的 MCP 資產有 SDK 更新政策，十月就是政策必須觸發兩次的月份。如果沒有，上述公告就是會累積下來的東西。

Smithery：分發層的合約到期

第三個事件是維運團隊今天就能感受到的。Smithery 的通知毫不含糊：2026 年 10 月 31 日，Smithery 關停其連線管理服務——這意味著每一個 run.tools 與 server.smithery.ai 伺服器 URL、託管代理路徑、API、帳戶、API key 與 CLI 都已失效。smithery.ai 目錄仍以公開目錄的形式維持線上服務，並由 Arcade.dev 支持。

對擁有供應商原生端點的伺服器，遷移是直接的——Smithery 自己的範例就是從 linear.run.tools 指向 mcp.linear.app/mcp。對把代理當作分發策略來建置的部署，這是一場搶跑：沒有供應商原生 URL，沒有約定由什麼在你的控制面裡接替它，而在記錄流量的代理消失之後，也沒有稽核說明現在是誰在連線。

這條教訓的適用範圍超出一家供應商：如果你的代理隊伍解析 MCP 伺服器所經過的端點屬於第三方，該端點的生命週期就是一項你既未選擇也未跟蹤的依賴。十月交付了這一證明——而且是在協定把發現元數據標準化、固定自身發布日曆的同一個月份。持久的立場是供應商原生端點（按 Smithery 自己的遷移指引），或由你的團隊營運的端點——我們的 MCP 伺服器防護分析為邊界所畫出的 buy-vs-build 分界線，這份紀錄在分發層給出了證明。

B2B MCP 部署的維運清單

圖註：六項控制，把十月的訊號轉化為部署政策——每一項都對應本月一個有日期的事件。

#	控制	它回應的十月事件	在部署中的樣子
1	鎖定規範版本	十月沒有新規範版本；下一版本 2027 年 3 月下旬	顯式鎖定 2026-07-28；執行宣告支援該版本的 SDK；在每個日曆節點複審鎖定
2	把發布節點寫進日曆	SEP-3398：三月與九月的最後一個週二	把 soft freeze（T−2.5 個月）與 hard freeze（T−1 個月）作為審查窗口排進團隊路線圖，而不是當作意外
3	停留在 SDK 安全軌道	十月 31 份公告；Inspector 1.0.3 中兩份嚴重級	把 SDK 地板鎖定在安全版本（TS ≥ 2.3.0，Inspector ≥ 1.0.3）；訂閱官方儲存庫的公告流
4	優先供應商原生或自營運端點	Smithery 的 `run.tools` / `server.smithery.ai` 於 10 月 31 日停服	盤點伺服器清單中的每一個非供應商端點；終止依賴代理的路由，或自行營運
5	為 Server Cards 元數據而設計	SEP-2127 於 10 月 6 日成為 Final，SDK/用戶端支援在後	建置端點時預留 card 位置；讓伺服器清單隨時可以變成可發現的元數據，而非設定
6	把註冊表收錄視為未審核	官方註冊表 52,141 台伺服器，66% 提供遠端端點（按 eSEOspace 的統計）	收錄不是安全訊號；在第三方伺服器接入之前，執行治理清單的模組審批門

這對 2026-07-28 部署模式意味著什麼

我們先前分析所給出的無狀態核心，是十月沒有觸及的部分——而這正是值得直白說出的重點。SEP-3398 重新安排未來的發布；它不動你整個冬季鎖定的規範。Server Cards 增加發現能力，不改變傳輸。公告在同一個協定版本上加固 SDK。Smithery 的關停是第三方的商業決定，不是協定事件。

如果你的部署模式假設 MCP 迭代太快而無法鎖定、太年輕而無法排期，十月就是這份假設的反證紀錄。從盯 changelog 轉為盯日曆的團隊，會把 2027 年 3 月下旬的發布當作一次按期複審；其餘團隊將從一次故障中得知它。