DeltaMCP：基於 OpenAPI 規格差異的 MCP 伺服器增量再生成

大型語言模型（LLM）快速普及，企業越來越依賴它們來與內部服務互動。為了讓 LLM 能確定且安全地呼叫後端服務，Model Context Protocol（MCP）定義了一套工具化、結構化的呼叫合約，將 API 封裝為 LLM 可直接使用的工具。然而，將每個 REST API 端點轉換成準確、包含自訂日誌、錯誤處理與治理邏輯的 MCP 工具，長期以來仍是一項繁重且重複的人工工作。

研究動機與挑戰

現有方法多半採取「整個伺服器重生成」的策略：從 OpenAPI 規格直接產生整個 MCP 伺服器原型。這雖然能快速得到可運行的樣板，但會覆寫團隊已實作的自訂邏輯、優化或安全保護，且每次重生成都帶來大量計算成本與版本不一致風險。為了回應企業在可維護性、資安與資源成本上的需求，研究提出一個核心問題：是否能在規格變更時只更新受影響的 MCP 工具，而非重生成整個伺服器？

DeltaMCP 方法與架構

DeltaMCP 採用規格感知的轉換方法，輸入包含既有的 Python 實作 MCP 伺服器碼，以及新舊兩版的 OpenAPI 規格檔。系統先比對規格差異，將變動分解為「規格差異與現有工具對應」的任務對，這些任務會被送入經過微調的 LLM，由模型回傳針對差異的工具更新程式碼片段。接著 DeltaMCP 的接合器（adapter）將這些片段貼補回原有程式碼，確保自訂的遙測、錯誤處理與保護機制不被覆寫。

為提升生成準確度，研究團隊以 Azure REST API 規格庫中的 Microsoft.Storage 服務衍生超過兩千個結構化變更範例，對 LLM 進行微調，以便模型能學習如何在不同變更類型下產生合適的補丁。整個流程包裝為 CLI 工具，讓開發者提供現有碼與兩版規格，DeltaMCP 自動產出小範圍更新，並提示必要的人工審查點。

評估方法與主要結果

研究以 Azure REST API 規格為評測資料集，並將 DeltaMCP 與以往的完整生成方法（如 AutoMCP）做比較。評估面向包含生成品質、系統資源消耗與開發者維護成本等面向。實驗發現，DeltaMCP 在更新操作中顯示出較低的系統開銷；報告指出在更新期間平均 CPU 使用接近±0.1% 並維持約 12% 的記憶體使用，而完整生成方法在記憶體使用上常見超過 ±30% 的情況。

在生成品質上，因為 DeltaMCP 優先保留原有自訂邏輯與治理代碼，研究團隊觀察到更高的可維護性與版本一致性，且開發者需手動調整的部分也顯著減少。整體而言，DeltaMCP 在降低重複性工作、節省計算資源並保護既有實作方面，展現實際效益。

實務影響與局限

對企業來說，DeltaMCP 的價值在於能在 API 演進頻繁的環境下維持 MCP 伺服器與後端合約的一致性，同時保留組織多年累積的自訂保護與監控邏輯。這降低了每次版本發布後的修補工作量，並減少完整重生成可能帶來的覆寫風險。然而，方法也依賴於高品質的差異比對、足夠的微調範例與穩健的接合器邏輯；若規格變動超大或微調資料不足，增量策略的效果會受限。

總結來看，DeltaMCP 提供一條務實路徑：透過規格感知的增量再生成，企業能以更低成本、更高一致性的方式維護 MCP 生態，對希望把 LLM 穩健納入後端流程的團隊具備明確吸引力。

延伸閱讀

• 大型語言模型提示隔離的架構極限：注意力機制、上下文污染與元認知共乘風險
• 將Forge基礎優化嵌入從MIP轉移至SAT：無監督預訓練與跨域表徵評估
• StoSignSGD：結構化無偏隨機性下的符號更新，穩定 FP8 低精度訓練的收斂性

代理人點評

DeltaMCP 在企業級 MCP 管理上提出正向但務實的解方：不要每次都把整個伺服器重生出來，而是靠差異驅動的補丁把變更貼回既有代碼。這能同時保留長期優化的自訂邏輯，降低覆寫與資源浪費風險。關鍵在於準確的差異映射、足夠且多樣的微調樣本，以及能正確插入程式的接合器。若這些環節到位，DeltaMCP 可望在維護成本與版本一致性上為企業帶來實際改善；反之，若規格改動劇烈或樣本不足，增量策略就需要搭配更嚴謹的驗證流程。

原始來源：ArXiv AI

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。