MCP Server 這陣子很容易被團隊誤會成「把內部 API 包一包，讓 Claude 或 agent 會叫工具」。

這個理解不能說錯，但太淺。真正的坑也在這裡：如果你只是把幾個 endpoint 快速接成 tool，MCP 很快會變成另一層散亂膠水。看起來很現代，實際上只是把以前的 integration debt 換了個名字。

我的判斷是：MCP 值得導入，但前提是你把它當成 AI 工具介面的產品層，而不是 demo 腳本的延長線。

MCP 最有價值的地方，不是協定本身有多神，而是它逼你把「模型可以做什麼」整理成一組明確介面。這對企業或產品團隊很重要。因為 agent 一旦能查資料、改資料、發通知、開 ticket、部署服務，問題就不再是模型會不會呼叫 API，而是權限、輸入、輸出、副作用、錯誤、審計與回滾要怎麼定義。

適合導入 MCP 的團隊，通常有三種。

第一種，是已經有多個 AI client 或 agent runtime 的團隊。今天用 Claude Desktop，明天用 Cursor，後天有內部 agent 平台。如果每個地方都各自接工具，很快就會重複造輪子。MCP 可以把工具能力集中在一層，讓不同 client 共用。

第二種，是內部系統多、但 API 文件和使用方式很分散的組織。MCP Server 可以把「查訂單」「找文件」「建 issue」「讀報表」這些能力包成模型容易理解、工程師也能維護的工具集合。

第三種，是正在把 agent 從個人自動化推向團隊工作流的人。這時候工具不只是方便，而是風險邊界。哪些工具只能讀？哪些可以寫？哪些要人工確認？哪些一定要留下操作紀錄？這些都應該在 MCP 層就想清楚。

但不適合的人也很明確。

如果你只有一個簡單 chatbot，沒有跨工具、跨系統、跨 client 的需求，MCP 可能只是多一層複雜度。如果你的工具本身還沒穩定，先急著包 MCP，只會讓底層混亂被放大。如果團隊沒有能力維護權限、測試、版本與 observability，那 MCP Server 很容易變成「誰都能加 tool，但沒人知道壞在哪」的黑箱。

最常見的踩坑，是把 tool 設計成「人類 API 文件的薄包裝」。例如 update_customer_status(customer_id, status) 看起來很乾淨，但模型不知道何時該用、用錯會怎樣、狀態值有什麼限制、是否需要確認、失敗後要不要重試。對 agent 來說，好工具不是只要參數少，而是意圖清楚、邊界清楚、錯誤可恢復。

第二個坑，是沒有區分 read tool 和 write tool。讀資料的工具可以比較寬，寫入或外部副作用工具一定要保守。尤其是發信、刪資料、改訂單、觸發部署這類操作，最好有 dry-run、確認摘要、權限檢查與審計紀錄。不然你不是在做 agent automation，而是在讓不穩定的推理結果直接碰生產系統。

第三個坑，是沒有版本治理。MCP Server 一旦被多個 client 使用，工具 schema 就是合約。隨手改欄位、改語意、改錯誤訊息，都可能讓 agent 行為漂移。比較務實的做法，是把 MCP tools 當 API product 管：命名規則、描述品質、測試案例、範例輸入、相容性策略，都要有人負責。

所以我的採用建議很簡單：不要從「我們要不要支援 MCP」開始，而是從「哪些能力值得變成可治理的 AI tool」開始。

先挑一組高頻、低風險、可觀測的讀取型工具，例如搜尋文件、查 issue、查 CRM 摘要。等你能穩定追蹤模型怎麼選工具、輸入是否合理、錯誤是否可理解，再逐步加入寫入型工具與人工確認。

MCP 的價值不是讓 agent 看起來更會做事，而是讓 agent 做事時比較不像在亂摸你的內部系統。把它當產品介面，你會得到可複用的 AI 工具層；把它當膠水，你只是多養一個未來會痛的目錄。