GitHub MCP Server 支援 Stateless MCP：連線端先檢查什麼

2026-07-26

AI

MCP

/

GitHub

/

AI

/

開發工具

/

遷移指南

GitHub 在 7 月 23 日宣布 GitHub MCP Server 已支援下一版 MCP 規格；官方公告指出核心協定將在 7 月 28 日轉為 stateless，並移除 session 與 initialize。如果你只是把 GitHub MCP Server 接到現成 client，官方表示 Tier 1 SDK 已保留向後相容性，通常不需要為了這件事立刻改設定；真正要先盤點的是自己包了一層 client、proxy 或連線健康檢查的情況。

這篇的重點不是重做先前的 MCP 棄用 capability 遷移，而是確認連線生命週期是否偷偷假設「每個 MCP 對話都有 session」。

先找出對 session 與 initialize 的假設#

下列搜尋不會判定程式有錯，但能快速找出要人工檢查的位置：

1
rg -n "initialize|sessionId|mcp-session|connectionId|handshake" src test scripts

命中後，分成三類看：

實作位置	需要確認的事	不要直接做的事
MCP client	是否把 `initialize` 成功當成唯一可呼叫工具的前提	看到新規格就刪除舊 client 支援
reverse proxy	是否依 session header 做黏著路由、快取或 rate limit	假設所有 request 都含舊 session 值
observability	trace 是否以 request 與 tool call 為單位關聯	把 session ID 當作唯一審計鍵

GitHub 說明它已移除 Redis session；同時，為了記錄與 secret scanning，會從新規格保證存在的 HTTP header 讀取必要資訊。這是 server 端的改造，不代表第三方 proxy 也能自行猜測或改寫協定欄位。

把連線測試改成「獨立 request 仍可完成」#

最小測試不必先追求完整 conformance suite。先在你的實際 client 與 GitHub MCP Server 間跑一個唯讀工具，並確認兩件事：重新建立 transport 後仍能列出或呼叫預期工具；失敗紀錄能對應到單次 request，而不是只能靠 session 找回。

1
Case A：同一個 client process 連續呼叫兩個唯讀工具
2
預期：兩次回應都可完成，且 log 可分別追溯。
3

4
Case B：重啟 client 或重新建立 transport 後呼叫同一工具
5
預期：不需依賴前一次 request 的 server-side session 才能完成。

如果你維護自己的 MCP server，官方公告也提到 conformance tests 已成為正式工具。把測試放到 CI 前，先確認目標規格版本與 SDK 支援範圍；不要把「GitHub 已升級」推論成所有自製 server 都自動相容。

Elicitation 要測的是每一步，不是只有第一次登入#

GitHub MCP Server 的 stdio server 會用 URL elicitation 協助登入。公告特別指出：在新協定版本中，每個 elicitation step 是獨立 HTTP request；官方 Go SDK 以 wrapper 同時處理舊、新 client。若你的 client 會把登入 callback、授權狀態或使用者核准綁在單一長連線，應測試「中間 request 不帶前一輪 session」的結果。

這裡最重要的安全界線仍是使用者核准。連線變快或改成 stateless，不等於可跳過登入確認、把 URL callback 自動接受，或放寬工具權限。