昨天我們透過內建的 Google 搜尋，輕鬆讓 Agent 具備了上網查資料的能力。但當我們回到企業內部，真正的挑戰才剛開始。

假設你寫了一支 Java API，用來查詢公司內部的「員工剩餘特休天數」。如果我們希望 Dify 的 Agent、工程師 IDE 裡的 Cursor，以及主管手機裡的 Claude Desktop 都能呼叫這支 API，過去我們必須針對這三個不同的平台，分別撰寫三套完全不同的外掛 (Plugin) 或匯入三次複雜的 OpenAPI/Swagger 規格書。這就是典型的「義大利麵條式系統整合」，極度難以維護。

為了解決這個 O(M×N) 的整合噩夢，技術圈近期掀起了一場架構革命。今天我們要挑戰最前沿的標準協定：MCP (Model Context Protocol)。

1. 什麼是 MCP？
MCP 最初由 Anthropic (Claude 的母公司) 提出，現在已迅速成為開源界的統一標準。你可以把 MCP 想像成「AI 應用的 USB Type-C 介面」。
過去每台手機都有專屬的充電線；現在只要支援 Type-C，任何設備都能互通。同理，只要你將後端 API 封裝成一個「MCP 伺服器 (MCP Server)」，任何支援 MCP 協定的 AI 客戶端（如 Dify）插上去，就能無縫讀取你的資料與工具。

2. MCP 伺服器的核心元件：Tools (工具)
MCP 協定主要提供三種能力：Resources (靜態資源)、Prompts (提示詞模板) 以及 Tools (可執行的工具)。針對今天的 Agent 實戰，我們專注於 Tools。
在開發 MCP 伺服器時（目前主流有 Python、TypeScript SDK，Java 社群也正快速跟上），我們只需要定義兩件事：

• 工具規格 (Schema)： 告訴 AI 這個工具叫 query_leave_days，需要傳入 employee_id (字串型別)。

• 執行邏輯 (Execution)： 當 AI 呼叫這個工具時，背後實際執行的 Java/SQL 查詢代碼。

3. 讓 Dify Agent 裝上 Type-C 擴充模組
當你的 MCP 伺服器在本地端跑起來後（別忘了搭配我們 Day 17 學到的 ngrok 取得公開網址），回到 Dify 的工具頁面。
你不需要再手動貼上一大串又臭又長的 JSON 規格書，只需要選擇「新增 MCP 工具」，填入你的 ngrok 網址。Dify 會主動向你的 MCP 伺服器發起握手 (Handshake)，瞬間自動發現並載入 query_leave_days 這個工具。

將這個工具掛載到 Agent 上，預覽測試：

你：「請問員工 A1234 還有幾天特休？」
Agent 的 ReAct 軌跡：

• 思考：我需要查詢特休天數，剛好手邊有 query_leave_days 工具。

• 行動：呼叫 MCP 伺服器，傳入 {"employee_id": "A1234"}。

• 觀察：MCP 回傳 {"days_left": 5}。

• 最終回答：「員工 A1234 目前還有 5 天特休喔！」

透過實作 MCP 伺服器，你展現了頂尖軟體工程師最重視的「解耦 (Decoupling) 思維」。你的後端業務邏輯完全獨立，AI 平台隨時可以抽換，架構變得極度優雅且具備強大的擴充性。

到今天為止，我們的 Agent 已經具備了強大的思考力與工具箱。但在單兵作戰的極限下，遇到極度複雜的大型任務，一個 Agent 往往會陷入思考死結。