MCP 值得看，因為它解決了一個真問題：agent 要用工具時，不能每個產品、每個框架、每個內部服務都重新發明一套連接方式。

以前做 AI agent，常見情況是模型端一套 tool schema，後端一套 API wrapper，桌面環境一套 plugin，內部系統又一套自訂 adapter。接到第三個工具時還能忍，接到第十個就開始失控。MCP 的價值，是把「模型或 agent 如何發現、描述、呼叫工具」變成比較一致的協議。這對正在做內部 AI 助理、開發者工具、資料查詢助理、文件工作流的人，很有吸引力。

但導入 MCP 最容易踩的坑，是把「工具連接標準」誤會成「安全邊界」。MCP 可以讓 agent 更容易看到有哪些工具、每個工具需要什麼參數、回傳什麼結果；它不會自動幫你判斷這個工具該不該被呼叫、這次呼叫需不需要人類批准、資料能不能離開系統、錯了要怎麼追責。

適合導入 MCP 的團隊，通常已經有明確的工具需求。像是工程團隊想讓 AI 查 issue、讀 repo、跑 CI、看 log；營運團隊想讓助理跨 Notion、Sheets、CRM 做查詢；或平台團隊想把內部服務整理成一組可被不同 agent client 使用的能力。這時 MCP 的好處很實在：少寫一堆一次性 glue code，也比較容易把工具能力做成可管理的清單。

不適合的人也很明確。如果你的 agent 還停在聊天、摘要、簡單 RAG，沒有穩定的 action 場景，先導入 MCP 可能只是多一層複雜度。若你的公司連「哪些資料可讀、哪些動作可寫、哪些操作必須審批」都還沒定義好，MCP 也不會替你定義。更麻煩的是，工具一旦標準化，agent 呼叫工具的成本會下降，風險反而可能上升。

我會把 MCP 放在基礎設施層，而不是產品魔法層。健康做法是先從 read-only 工具開始，像搜尋文件、查詢 ticket、讀部署狀態；再逐步開 draft action，例如產生草稿、建立待審核任務；最後才開真正會寫入外部系統的 action。每一級都要有 logging、rate limit、使用者身份、審批規則和失敗回復。

我的判斷：MCP 適合「工具數量正在變多」的團隊，不適合「還不知道 agent 要做什麼」的團隊。它能降低整合成本，但不能降低治理責任。把它當插座，很好；把它當保險絲，就危險了。