MCP 棄用 Roots、Sampling、Logging 前：先做能力盤點與遷移清單
如果你維護的 MCP server 只提供 tools，這次變更不一定會碰到你；但只要 client 或 server 宣告過 Roots、Sampling 或 Logging capability，就值得先盤點。MCP 的 SEP-2577 已是 Final Standards Track，將這三項核心功能標記為棄用；它描述的是過渡期的規則，不是要求所有實作立刻刪除程式碼。
近期社群有人把這件事包裝成「MCP v2 deadline」，但正式文件的重點其實比較務實：棄用期內 wire-level 行為不變，既有 capability negotiation 仍要正確處理。真正該做的是確認你有沒有依賴它們，並把替代方案與相容性測試排進工作。
先分清楚：棄用不等於現在就不能用
SEP-2577 指出，Roots、Sampling 與 Logging 在納入該 SEP 的規格版本開始棄用；在過渡期中，型別不會被移除、capability negotiation 也不會改變。新實作不應再為這些功能新增支援，既有實作則應繼續正確處理它們，並可在協商到棄用 capability 時發出警告。
所以第一個危險動作不是「忘了升級」，而是看到棄用就直接移除 capability 或 handler。這可能讓仍使用舊協定版本的 client／server 失去相容性。先確定協定版本、相對端能力與你自己的相容性承諾，才決定何時移除。
用 capability 清單找出真正的依賴
在程式碼庫搜尋這些字串，先把直接與間接使用處列出來：
rg -n "roots|sampling/createMessage|logging/setLevel|notifications/message|ServerCapabilities\.logging" .接著用表格記錄每個命中點。不要只看 SDK 版本，因為真正會影響相容性的，是初始化時宣告的能力、送出的 JSON-RPC method 與對端是否真的依賴回應。
| 功能 | 先確認什麼 | 過渡期處理 | 可評估的替代方向 |
|---|---|---|---|
| Roots | server 是否呼叫 roots/list，或用 roots 當檔案授權邊界 | 保留既有 handler 與 capability；加入棄用警告 | 明確工具參數、resource URI、server 設定或環境變數 |
| Sampling | server 是否要求 client 代為呼叫模型 | 保持使用者核准與既有流程 | 由 server 明確整合受控的模型提供者，或重設工作流程 |
| Logging | 是否透過 MCP 傳送 log level 或 log notification | 不要讓移除計畫吞掉診斷資料 | stdio 的 stderr 或既有 OpenTelemetry 管線 |
這張表能讓你把「依賴」與「曾經出現過」分開。例如某個 SDK 型別仍存在，不代表 production workflow 真的會送出對應 method。
Roots 不能當作唯一的檔案授權邊界
正式規格把 Roots 描述為 client 提供給 server 的 URI 或檔案系統邊界資訊；SEP-2577 也指出它的語意是 informational，server 不一定必須遵守。這表示即使目前仍支援 Roots，也不該把它當成唯一的存取控制。
若工具會讀寫檔案，較清楚的做法是把允許的路徑放進工具參數或 server 設定，然後在 server 端自行驗證 canonical path 是否位於允許的資料夾。MCP 的安全原則也要求 host 取得使用者同意，並讓使用者理解會分享哪些資料與執行哪些動作。
允許目錄：/workspace/project工具輸入：relativePath = "docs/plan.md"server 驗證：解析後的 canonical path 仍在允許目錄內這不是要把每個 server 都變成檔案系統 sandbox，而是避免把一個資訊性 capability 誤當成存取控制機制。
Sampling 與 Logging 要分別找對替代路徑
Sampling 的問題不只是 API 更換。規格要求使用者明確核准 sampling request，且能控制是否執行、送出的 prompt 與 server 可看到的結果。若你改成 server 直接呼叫模型 API，就必須重新設計帳務、模型選擇、資料最小化與審核點，不能把它當成無痛替換。
Logging 則相反：它通常不需要留在 MCP 的 application-protocol channel。SEP-2577 提到 stdio transport 可用 stderr，結構化可觀測性可用 OpenTelemetry。遷移前先確認 log 是否含有 token、prompt 或使用者資料，並讓錯誤追蹤與正常輸出分流。
以協商測試保住舊 client 與新版本
在真正移除任何程式碼前，至少保留兩組整合測試：
Case A：相對端宣告或使用棄用 capability預期：仍可完成既有協定流程；記錄清楚的棄用警告。
Case B：相對端不宣告棄用 capability預期：server 不主動呼叫舊 method；替代路徑可以完成同一個任務。這比單純跑 unit test 更接近 MCP 的實際風險，因為 capability negotiation 本來就是 host、client、server 之間的契約。正式規格也提醒，工具代表任意程式碼執行路徑，host 在呼叫前必須取得使用者明確同意；遷移期間更不該為了相容性而自動放寬操作權限。
這次遷移的完成條件
完成不是把搜尋結果中的舊字串全部刪掉，而是能回答四件事：哪些 capability 正在 production 使用、哪些相對端仍需要它、替代路徑是否保留了同等或更小的權限，以及兩種協商情境是否都有測試。先完成這份盤點，才能選一個不破壞現有使用者的移除時機。
常見問題
Q: SEP 標為 Final，是否代表必須立刻刪掉 Roots、Sampling 與 Logging？
A: 不代表。SEP-2577 說明棄用期內不移除型別、不改變 wire-level 行為，既有實作仍應正確處理對應 capability。應先依協定版本與相容性需求安排遷移。
Q: 我只用 MCP tools，還需要做這份盤點嗎？
A: 仍值得做一次快速搜尋，確認 SDK、共用 middleware 或測試 fixture 沒有宣告這些 capability。若沒有依賴，記錄結果即可，不必為了棄用而重寫正常的 tools 流程。
Q: 用 Roots 限制目錄後，還需要自己做路徑驗證嗎？
A: 需要。Roots 是資訊性指引，並非強制的授權控制。凡是可能讀寫檔案的 server，都應在自身邊界驗證允許路徑與操作。
參考資料：
回報錯字、失效連結，或告訴我你想看的延伸主題。