最近很多團隊導入 MCP Server 的第一個直覺，是把它當成「AI 版 API Gateway」：CRM 有 API，就包一個工具；工單系統有 API，也包一個工具；資料庫、Slack、內部後台、部署平台全部接上，然後期待 agent 從此變成萬能員工。這個方向很容易看起來進度飛快，但實際上通常是在累積新的混亂。

MCP 的價值不是「讓模型碰到更多按鈕」，而是讓模型在一個清楚、穩定、可描述的邊界裡完成任務。API 是給程式呼叫的，工具是給 agent 判斷何時使用的。兩者差別很大。API 可以假設呼叫者知道資料模型、錯誤碼、前置條件和交易語意；agent tool 則必須讓模型只靠名稱、描述、參數和回傳結果，就能做出足夠好的下一步判斷。你把一堆底層端點原封不動丟給它，不是賦能，而是把產品設計責任外包給模型。

比較好的導入方式，是先挑「高頻、低歧義、可回滾或可審計」的工作流。像是查某個客戶的付款狀態、整理今天失敗的 CI、根據 issue id 產生診斷摘要、建立一張草稿工單、查詢部署版本與最近錯誤。這些工具不一定要很通用，反而應該有明確意圖。get_customer_billing_status 通常比 query_database 更適合 agent；create_draft_refund_request 也比 post_to_admin_api 安全得多。

真正不適合 MCP 化的，是那些需要大量人類脈絡、權限後果很重、或參數空間太自由的操作。例如直接改正式資料、任意執行 SQL、批次寄信給客戶、修改權限、部署到 production。這些不是永遠不能做，而是不能只靠「工具描述寫清楚一點」就上線。至少要有 dry run、審批、範圍限制、審計紀錄，以及失敗後能理解的回報。

所以我的判斷是：MCP Server 很值得做，但第一版不要追求覆蓋率。你要問的不是「我們有多少 API 被 AI 接上」，而是「哪些流程被 AI 接手後，結果更穩、更快、更可控」。適合導入 MCP 的團隊，通常已經有明確內部流程、知道誰能做什麼、也願意把工具當產品維護。不適合的是只想把後台全部開給模型，然後期待 prompt 幫忙治理權限和商業邏輯。

一句話：MCP Server 不是 API 的展示櫃，而是 agent 的操作介面。工具越多不一定越強；邊界越清楚，才越可能真的省時間。