MCP Servers v2.0.0 在保留舊版客戶端支援的同時加入現代協議支援

MCP Servers v2.0.0 為現代協議重構了專案的參考伺服器，同時保留對舊版客戶端的支援。這項更新於 10 月 19 日發布，銜接不同世代的 MCP；MCP 即 Model Context Protocol，用於將 AI 應用程式連接至工具及資料。其相容性承諾有明確界線：舊版客戶端仍受支援，但 TypeScript 伺服器現時需要 Node.js 24。

這項分別令維護既有整合的開發者面對壓力。客戶端仍可使用較舊的協議通訊，但其工具背後的軟件卻可能需要較新的執行環境。因此，應用程式團隊須分別就伺服器套件、執行環境及協議行為作出決定。

核心張力在於現代化與延續性之間。維護者正將其範例遷移至較新的架構，卻不要求每個已連接的應用程式同時遷移。對使用 Claude Desktop、VS Code 或自訂 AI 應用程式的開發者而言，眼前問題是哪些既有假設能在這次轉變中保留。相較於版本號本身，連線設定、檔案權限及應用程式狀態的存續時間更值得仔細檢視。

MCP Servers v2.0.0 實際改變了甚麼

此次發布更新的是一組明確界定的參考實作，而非整個 MCP 社群中的所有伺服器。

發布套件清單列出四個以 2.0.0 版本發布的 TypeScript 套件，涵蓋 Everything、Filesystem、Memory 及 Sequential Thinking。TypeScript 是一種為 JavaScript 加入型別檢查的程式語言。

同一版本亦列出三個 Python 套件：Fetch、Git 及 Time。它們採用日期式版本號 2026.10.19。當團隊盤點相依項目時，這個差異相當重要，因為儲存庫的發布標籤並不等同於每個套件的版本。

維護者將此更新描述為支援現代規格的重構，同時繼續回應舊版客戶端。這是針對所包含伺服器的實作說法，並不代表無關的社群整合，或所有經 MCP 連接的應用程式都必然相容。

當中亦涉及不同的版本系統。儲存庫發布使用 v2.0.0，而協議則使用日期式識別碼。套件版本識別已發布的軟件；協議識別碼則描述該軟件所支援的通訊規則。

混淆這些識別碼，可能會造成誤導性的升級預期。安裝標示為 2.0.0 的套件，並不代表應用程式會自動採用所有較新的協議功能。客戶端仍決定使用哪一種受支援的通訊行為。

這使 MCP 伺服器相容性成為元件之間的關係。一個伺服器套件可以支援多個協議修訂版本，而已連接的應用程式仍可繼續使用較早的修訂版本。相反，安裝較新的伺服器軟件亦無法補足客戶端欠缺的能力。

對工程經理而言，此次發布清楚區分了可用性與就緒狀態。已發布的套件證明該實作可供使用；是否就緒，則取決於周邊應用程式、啟動環境、權限及預期行為能否配合運作。

實際意義不只限於直接執行這些套件的人。參考實作提供範例，供其他開發者研究及改編。即使參考套件從未列入正式環境的相依清單，其架構選擇仍可影響自訂整合。

這種影響需要審慎措辭。範例可以建立一種模式，卻不能證明該模式適合每一種部署情況。這次發布提供具體的實作材料，但應用程式擁有人仍有責任判斷哪些部分適合其系統。

因此，這則消息比籠統地宣稱 MCP 已改變更具體。維護者已發布更新後的範例，把較新的協議行為與既有的大量舊版客戶端連接起來。下一個問題是執行這些範例所需的基礎設施。

舊版客戶端仍受支援，但舊版執行環境並非如此

協議相容性並不代表保留原有的執行環境。

此次發布的 Node.js 要求將 TypeScript 伺服器所需的最低 Node.js 版本提高至 24。Node.js 是在瀏覽器以外執行 JavaScript 的執行環境。這項變更適用於 Everything、Filesystem、Memory 及 Sequential Thinking。

相關的維護紀錄說明，為何這項要求值得注意。套件宣告、文件及自動化檢查此前描述了不同的支援預期。這次修正讓所宣告的最低版本、文件及驗證設定，都與較新的執行環境保持一致。

這為本機 AI 應用程式帶來具體的遷移問題。使用者可能更新伺服器套件，卻沒有改動應用程式的啟動環境。客戶端協議仍然可接受，但伺服器依然取決於該程序可取得的執行環境。

設想一部具獨立開發環境及桌面應用程式環境的工程工作站。終端機可以顯示符合要求的執行環境，但從其他位置啟動的應用程式可能繼承不同設定。終端機內成功執行，並不能確定桌面應用程式可否啟動同一個伺服器。

這個例子說明部署推理，而非報道此次發布中的缺陷。更廣泛的含意直接來自新的最低要求：團隊需要掌握實際啟動套件的環境證據。

壓力最直接落在發布設定的開發者、維護受管理工作站的管理員，以及封裝內部助理工具的團隊身上。他們的責任包括啟動工具的軟件，而不只是工具所宣告的介面。

對這些團隊而言，向後相容可以減少協調工作，但不能完全消除。他們未必需要立即重寫舊版客戶端，卻仍須考慮新版伺服器的要求。

這項分別亦改變了詮釋故障的方式。無法啟動的程序，與正在運行卻拒絕請求的伺服器，是不同類型的問題。把兩者都視作協議不相容，會令調查走向錯誤的元件。

同一推理也適用於支援文件。若指引只說明舊版客戶端仍受支援，便應在附近補充執行環境要求的背景。否則，讀者有理由推斷維護者作出了比實際更廣泛的承諾。

套件固定版本，即把相依項目固定於指定版本，成為具有明顯後果的營運選擇。團隊可以審慎評估這次新發布，而不是把突如其來的套件變更與環境變更混在一起。

這並不構成延後更新的普遍理由，而是顯示需要區分更新的原因。尋求現代協議行為的團隊，與維持既有工作流程的團隊，短期目標不同。

此次發布為兩類團隊都提供了前進路徑，但其驗證方式應反映這些不同目標。維持舊版客戶端意味著檢查行為是否持續正常；採用較新客戶端則同時意味著檢視處理其請求的架構。

相容性橋樑改變請求攜帶內容的方式

即使可見工具仍然熟悉，較新的架構亦改變了通訊內容的存放位置。

根據現行的協議版本控制規則，協議修訂版本為 2026-07-28。請求透過中繼資料宣告其協議版本；中繼資料即隨請求附帶的描述性資訊。伺服器會按其支援的版本，逐一接受或拒絕請求。

客戶端可使用 server/discover，這是一項回傳伺服器身分、支援版本及能力的探索請求。較舊的協議修訂版本則使用初始化交握，即建立連線運作內容的開場交換程序。

現代協議實作將兩種方式帶進 TypeScript 參考伺服器。對本機連線而言，第一個訊息會選定協議世代。舊版客戶端以 initialize 開始；現代客戶端則使用探索功能或較新的請求中繼資料。

該實作亦不再依賴按工作階段識別碼索引的伺服器狀態。連線專屬狀態存放於伺服器實例上。需要在現代請求之後持續存在的資訊，則使用 handles，即由伺服器發出的識別碼，用以參照相關資訊。

這些細節很重要，因為「無狀態」容易被誤解。不再依賴協議工作階段，並不表示應用程式每次請求後都會忘記所有資料；而是表示開發者必須明確辨識資訊存放何處，以及後續工作如何引用該資訊。

對自訂整合而言，這項分別影響架構審查。開發者需要區分屬於單一請求的資訊、屬於某個連線的資訊，以及已儲存的應用程式資料。這些生命週期不一定相同。

助理保留一項專案事實，與工具保留暫時進度，代表不同要求。持久資訊應按產品的儲存規則保留；暫時資訊則只應在預定操作或互動期間可用。

Memory 伺服器正好說明這項差異。它的知識圖譜是一種透過關係連結實體的結構，提供持久資訊。其文件描述現代及舊版客戶端採用不同的訂閱機制，同時保留相同的底層工具及資源。

訂閱是要求在資訊變更時接收更新。重要的產品問題在於應用程式是否持續收到這些更新。首次讀取成功，並不能證明後續變更會如預期般出現。

Sequential Thinking 又呈現另一種生命週期差異。其文件描述在兩個協議世代中，思考歷史均會在連線期間持續存在。這種行為涉及工具的工作內容，而非對永久記憶的一般承諾。

Everything 的用途則不同。它為客戶端建構者測試協議能力，包括現代請求及通知行為。它的價值在於呈現整合行為；單一次成功的工具呼叫未必能檢視到這些行為。

綜合而言，這些範例顯示 MCP 伺服器遷移不僅是更改匯入內容或套件名稱。可見功能可以保持熟悉，周邊的通訊模型卻可能改變。改編參考程式碼的開發者需要理解兩個層面。

這亦正是相容性方案的重要之處。支援舊版客戶端，為應用程式團隊爭取了時間；但在採用新架構行為前，團隊仍須理解其運作方式。

檔案系統存取令行為差異變得具體

同一個伺服器套件，可能因應客戶端所處的協定時代而需要不同的權限設定。

Filesystem 伺服器提供了最清楚的例子，因為它的行為會影響工具可存取哪些本機目錄。允許清單是明確列出的獲准位置集合。伺服器的現代連線會使用程序啟動時提供的目錄。

帶有標籤的目錄存取控制文件建議在各協定版本中使用這些啟動參數。較舊的客戶端亦可使用 Roots，這是由客戶端提供、用以描述檔案系統位置的機制。現代連線不會要求這些舊有資訊。

因此，未有以獲准目錄啟動的伺服器，會因其連線途徑而呈現不同的行為。對於現代工具呼叫，文件說明會出現錯誤，指出缺少目錄設定。僅有已連線的程序，並不代表已建立可用的檔案存取權限。

至於舊有客戶端，文件亦說明了存取權更新及撤銷的處理方式。當 Roots 重新整理仍在進行時，工具呼叫會等待。客戶端提供的 roots 生效後，如更新內容不含任何有效 roots，存取權便會被移除，直至有效 roots 再次提供為止。

產品層面的含意很直接：連線成功與權限成功是兩種不同結果。客戶端可以找到伺服器並識別其工具，但未必擁有通往目標檔案的有效存取途徑。

設想一個示例：助理協助工程師比較本機設計文件。客戶端升級前後，使用者的要求聽起來完全相同。然而，應用程式可能進入不同的協定路徑，並遇上不同的設定要求。

如果先前的安排依賴客戶端提供的 Roots，採用現代路徑時便必須留意啟動目錄。使用者的措辭不會揭示這項依賴關係。顯示存在檔案操作的工具清單亦不會揭示。

這正是為何權限應納入遷移分析，而非只作為腳註。檔案存取將協定行為直接連結至使用者期望。設定不相符，可能會令使用者以為系統缺乏知識，或以為助理未能理解要求。

這亦可能令疑難排解更複雜。團隊可能會調查檢索品質，即軟件尋找相關資訊的效能，但底層工具其實無法存取目標位置。此版本的文件有助區分這些可能性。

對於知識工作流程，團隊應區分連接器的存取邊界，與最終資訊系統的品質。可搜尋知識庫取決於相關文件是否可用、已妥善整理及可被檢索。協定支援只涵蓋這條鏈路的一部分。

這個例子亦限制了開發人員應從向後兼容性中推斷的內容。持續支援舊有行為，並不代表現代客戶端的權限設定完全相同。兩種路徑都可以獲支援，同時依賴不同機制。

對於正在評估助理的機構而言，這項差異帶來了一條具體的採購問題：哪個元件界定可存取的位置，而應用程式又如何傳達缺失或已撤回的存取權？答案應說明實際行為，而不只是列出支援的標準。

此版本令調查這個問題更容易，因為參考實作已記錄其邊界。其他整合仍需要各自的證據。複製協定標籤，並不能證明它們採用了等同的存取規則。