代理框架與標準
GitHub MCP Server 提前支援無狀態 MCP，新版移除連線階段與共享 session 儲存
GitHub MCP Server 已支援預定 7 月 28 日定稿的 MCP `2026-07-28` 規格，遠端請求不再依賴 `initialize` 握手及協定層 session。新設計簡化水平擴充，但 Tasks、錯誤碼和自訂客戶端仍有相容性工作要做。
GitHub 在 7 月 23 日宣布，官方 GitHub MCP Server 已提前支援 MCP `2026-07-28` 規格。這次改版的核心不是增加工具，而是重寫遠端代理工具的傳輸模型：`initialize`／`initialized` 握手與 `Mcp-Session-Id` 被移除，協定版本、客戶端資訊及能力改由每次請求攜帶。因此，同一代理的連續呼叫可被普通 round-robin 負載平衡器送往不同執行個體，不再需要 sticky session 或 Redis 等共享 session store。
為讓閘道在不解析 JSON-RPC payload 的情況下路由、限流及掃描流量，新規格要求 Streamable HTTP 帶上 `Mcp-Method`、`Mcp-Name` 等標頭；列表與資源讀取結果也可透過 `ttlMs`、`cacheScope`表達快取期限。GitHub 表示，其服務因此取消初始化時的資料庫寫入和每次呼叫的 session 讀取，也不再為日誌與祕密掃描做深度封包檢查。原先需要多輪互動的登入或 elicitation，則改成伺服器回傳 `InputRequiredResult`，待客戶端收集輸入後重新送出原請求。
這對自架 MCP 服務的工程團隊具有直接營運價值，但「無狀態」只限協定層；瀏覽器、購物車或工作流程狀態仍須以明確 handle 放入工具參數。新版同時把 Tasks 改為 extension、調整資源不存在的錯誤碼，並棄用 Roots、Sampling、Logging 等核心能力。Tier 1 SDK 雖保留舊版相容性，手寫協定、依賴舊 Tasks API或比對固定錯誤碼的實作仍應跑官方 conformance suite，不能把升級視為單純更換版本字串。