MCP 遷移 90 天計畫：Adapter First 實作指南

把既有 API、後台服務或 SaaS 工作流接進 Model Context Protocol（MCP），不需要一開始就「把全部系統改寫成 AI」。更穩妥的做法是先以 adapter 保留既有領域服務、權限與資料所有權，再把真正需要的能力以 MCP tool、resource 或 prompt 的形式逐步公開給 host。這篇提供一份給工程主管使用的 90 天執行框架：目標不是承諾 90 天消除所有技術債，而是在三個月內建立一條可測試、可觀測、可回退的遷移路徑。

核心原則：先讓 MCP 成為既有能力的受控入口，而不是新的「萬能代理層」。第一批只接低風險、可觀測、可回退的工作；寫入、金流、刪除、權限變更與敏感資料則保留明確的人為核准與更嚴格的上線門檻。

Adapter-first 是什麼？為什麼適合遷移期？

本文所說的 adapter-first，不是 MCP 規格中的專有名詞，而是一種工程遷移策略：既有系統仍保留它的領域邏輯、資料庫與原本 API；新增一層薄的 adapter，負責把 MCP 的工具輸入轉為既有服務可理解的請求，再把結果以穩定、可驗證的格式回傳。這能避免在協議剛導入時，同時重寫核心業務與 AI 整合，讓問題範圍失控。

MCP 的架構本身也支持這種責任分離：host 負責連線、使用者授權、同意與安全政策；每個 client 對應一個 server 的隔離連線；server 則提供範圍明確的資源、工具與 prompts。adapter 應該讓原有服務保持專注，讓 host 可以繼續掌握跨服務的安全邊界。

若要先理解相容性、舊整合保留與基本風險，可以先閱讀本站的〈MCP 遷移指南：保留既有整合並降低技術債風險〉；本篇則把重點放在工程主管如何安排三個月的交付節奏。

開始前：選對第一個遷移對象

第一個 MCP adapter 不應選「最重要」的服務，而要選能提供最多學習、又不會放大事故的服務。優先順序可從下列特徵判斷：

適合首波：查詢型、唯讀、輸入輸出明確、既有 API 穩定、已有測試與審計紀錄的能力。
可做第二波：可重試且具 idempotency 的更新操作，例如建立草稿、提出請求或排程前的預覽。
先不要接：不可逆刪除、付款或轉帳、管理員權限、跨租戶資料、未完成資料分類的個資操作。

先建立一份「能力清單」，每項都標記資料分類、擁有團隊、既有認證方式、是否有副作用、可否回退、需要哪些最小權限，以及失敗時的人工處理人。這份清單是遷移決策依據，不應只是一張工具名稱表。

第 1–15 天：盤點、切界與成功定義

先畫出三個邊界

對第一個候選能力，畫出「host → MCP server／adapter → 既有服務」的資料流。標示使用者身分在哪裡建立、adapter 可以讀到什麼、寫入最後由哪個服務授權，以及日誌由誰保存。不要讓 adapter 同時承擔業務規則、身分系統和資料轉換；它的責任越薄，後續越容易測試與替換。

把驗收指標寫在程式前

至少定義成功率、P95 延遲、每次呼叫的可追蹤 ID、錯誤分類覆蓋率、權限拒絕是否正確，以及是否能安全回退到原 API 流程。對有副作用的工具，再增加「是否顯示預覽」「誰核准」「是否可重送」「回滾責任人」四項條件。

這一階段的產物應包括：能力清單、資料流圖、風險分級、初版 tool contract、驗收門檻與停止條件。若這些還不清楚，就不應急著公開工具。

第 16–30 天：建立薄 adapter 與穩定合約

將第一個能力包成小而明確的 MCP 介面。例如「查詢客戶訂單狀態」要有固定輸入 schema、輸入驗證、可理解的錯誤碼與遮罩後的回應；不要把通用 SQL、任意 URL 或未過濾的管理 API 直接包成一把「萬用工具」。工具名稱、描述、輸入欄位與回傳格式都是模型的操作介面，模糊的合約會讓誤用更難被發現。

MCP 在初始化時由 client 與 server 宣告能力並進行協商。adapter 只應公開真的支援、已測試且已被授權的能力；不要為了「看起來完整」先宣告未實作的功能。若工具很多，host 也應考慮按需探索工具，避免所有工具定義一開始就佔滿模型的 context。

最少要有的控制點

所有輸入先做 schema、長度、格式與業務規則驗證。
為每次呼叫產生 correlation ID，串起 host、adapter 與既有服務日誌。
寫入型操作必須有 idempotency 設計、明確結果與失敗補償方式。
敏感欄位預設遮罩；日誌避免寫入 token、密碼、完整個資或模型不需要的內容。
將「預覽」和「執行」拆成不同工具或不同確認流程，不要讓自然語言一句話直接造成不可逆動作。

第 31–45 天：先把身分、權限與同意做對

遠端 MCP server 若使用 HTTP 授權，應以目前 MCP 授權規格與 OAuth 2.1 的要求設計。核心不是把既有 access token 原封不動轉送，而是讓 token 明確綁定目標 MCP resource、在 server 端驗證受眾與權限，並以最小 scope 開始；不足的權限應以明確的 step-up 流程要求，而不是一開始就給「全權」。

官方安全文件特別警告 token passthrough、代理 server 的 confused deputy、SSRF 與過度寬鬆 scope 等風險。因此，adapter 若還要呼叫上游 SaaS，應使用為該上游服務取得、且獨立於 MCP client token 的憑證與授權流程；每個權限提升、拒絕與同意都應留下可稽核紀錄。

本機 stdio server 的風險也不能被忽略：它可能以 host 的權限存取檔案或啟動程序。安裝前應顯示完整啟動命令、限制檔案與網路權限、使用受信任套件來源，並避免把高權限憑證放在模型可直接看到的環境中。

第 46–60 天：做不只「能跑」的測試

除了 unit test，遷移驗收應把舊 API 直連與 MCP adapter 並列比較：相同輸入是否得到等價的業務結果？錯誤時是否安全拒絕？逾時、重試、token 到期、scope 不足、意外輸入與下游 5xx 時，是否仍保有正確的日誌與回退行為？

對模型使用情境，另建立一組紅隊式案例：模糊指令、惡意 prompt、過長輸入、要求跨租戶資料、要求提升權限、URL 重新導向，以及試圖讓工具跳過確認的內容。目標不是讓模型「永不犯錯」，而是驗證系統在錯誤或惡意輸入下仍由 server-side 授權、驗證與資料邊界保護。

第 61–75 天：小流量試行，先觀測再擴大

以 feature flag 將第一批使用者限制在內部團隊或明確的試點群組；唯讀工具可以先開放，寫入工具則維持 preview-first 與人工核准。每天查看失敗率、延遲、被拒絕的 scope、工具選擇錯誤、敏感資料遮罩與回退次數。若發生權限越界、不可重試的副作用或無法追溯的錯誤，立即停用該工具，而不是只修 prompt。

第 76–90 天：正式化治理，而不是只宣布上線

在準備擴大前，請把以下項目納入正式交付：

每個 adapter 的 owner、服務等級目標、值班與事故處理流程。
工具 schema、權限與副作用的變更審查；避免悄悄改變既有工具語意。
版本相容性測試與 capability 變更紀錄。
金鑰輪替、token 失效、撤銷權限與離職帳號處理演練。
可在短時間內關閉 MCP 路徑並回到既有 API 的回退方式。

這才是 90 天計畫的真正終點：不是「所有服務都 MCP 化」，而是讓下一個 adapter 可以複用同一套合約、資安、測試與營運框架。

工程主管的每週檢查問題

本週新增的工具是否真的有清楚的業務 owner 與最小權限？
我們能否從一次使用者請求追到下游服務的實際動作與結果？
寫入操作是否先預覽、可否重複安全執行、失敗後由誰處理？
是否有工具為了方便而暴露過寬查詢、任意 URL、通用 shell 或管理權限？
若 host、token、上游 API 或模型行為出錯，是否能在不遺失資料的情況下停用並回退？

結論

adapter-first 的價值不在於讓 MCP 看起來像一層新架構，而在於讓團隊能以小範圍、可驗證的方式把既有能力帶進 AI 工作流。先選安全的首波能力、用薄 adapter 保留原服務、以最小權限與明確同意保護寫入動作，再以測試、觀測和回退管控擴大範圍，才能讓 MCP 遷移逐步降低整合風險與長期維運成本。

資料來源

Model Context Protocol：Architecture（host、client、server 的責任與 capability negotiation）
Model Context Protocol：Authorization（OAuth resource indicators、token audience、scope 與 token handling）
Model Context Protocol：Security Best Practices（token passthrough、confused deputy、SSRF、scope minimization）
Model Context Protocol：Client Best Practices（progressive tool discovery 與 sandboxed tool execution）