MCP（Model Context Protocol）完整解析：讓 AI 串接工具的 USB-C 標準

目錄

• MCP 是什麼：AI 世界的 USB-C
• 為什麼需要 MCP：從整合惡夢到隨插即用
• MCP 怎麼運作：三個角色、三種能力
• MCP 和 Function Call 是什麼關係？
• 對企業的價值，與不能忽略的風險
• 結語：當 AI 開始萬物互通

在《Function Call 是什麼？》的最後，我們留了一個伏筆：有一項技術，正在為整個 AI 工具生態鋪路。而在《AI 代理（AI Agent）是什麼？》裡，也不只一次提到，AI 之所以能動手調用外部工具，靠的就是「Function Call 或 MCP」。最近你大概也發現，幾乎每個 AI 產品都在主打同一句話——「支援 MCP 串接」。這個被反覆提起的 MCP，到底是什麼？這篇就由 EgentHub 一次講清楚：MCP（Model Context Protocol，模型上下文協定）是什麼、它想解決什麼麻煩、實際上怎麼運作，以及它和大家已經認識的 Function Call 又是什麼關係。

閱讀建議：這篇會接著《Function Call 是什麼？》的脈絡往下談。如果你對「AI 到底怎麼調用外部工具」還沒什麼概念，不妨先把那篇讀過一輪，再回頭看 MCP，理解起來會輕鬆許多。

MCP 是什麼：AI 世界的 USB-C

一句話講，MCP（Model Context Protocol）是一套開放的標準協定，專門規範「AI 應用該怎麼跟外部工具、資料源對接」。它由 Anthropic 在 2024 年底提出並開源，用意很單純：讓 AI 串接工具這件事有一套大家共用的規格，而不是每接一個工具，就得從頭刻一次連接方式。

要有畫面感的話，可以把 MCP 想成 AI 世界的 USB-C 集線器。

回想 Type-C 還沒普及的年代：手機、相機、筆電各有各的專用接頭，出門一趟得塞一整包充電線和轉接頭，換一台裝置就得換一條線。等到大家統一改用 USB-C，情況才變成「一條線走天下」——任何裝置配任何線都能通。

MCP 對 AI 扮演的正是這種統一接頭的角色：無論哪一個 AI 應用、想串接哪一套外部系統，只要兩邊都照著 MCP 協定走，就能直接插上、馬上互通。

小提醒：MCP 是一套協定（Protocol），既不是某個產品，也不是某個模型，而是大家事先講好的溝通規格。

為什麼需要 MCP：從整合惡夢到隨插即用

想看懂 MCP 的價值，得先回到它還沒出現的那段日子。

正如《Function Call 是什麼？》談過的，AI 想調用外部工具，前提是得先把工具接上來。麻煩在於，過去每一個 AI 應用要接上每一個工具，都得各自客製一套專屬的串接。

假設市面上有 10 個 AI 應用、100 個想串接的工具（資料庫、行事曆、CRM、ERP……），最糟的情況，就是得開發 10 × 100 = 1000 套客製整合。更頭痛的是，只要任何一邊改版，對接隨時可能壞掉。這種 M × N 的組合式膨脹，讓維護成本高到嚇人。

MCP 的解法，是把「M 乘以 N」壓成「M 加 N」：

• 每個 AI 應用，只要實作一次 MCP 的連接能力
• 每個工具，也只要實作一次 MCP 的對接程式
• 兩邊都到位後就能自動互通，不必再為每一組配對另外寫專屬程式

MCP 怎麼運作：三個角色、三種能力

MCP 的運作，拆成三個角色來看最清楚：

• MCP Host（主機）：你直接互動的 AI 應用本身，例如 Claude 桌面版、ChatGPT，或企業的 AI Agent 平台（如 EgentHub）。
• MCP Client（客戶端）：住在 Host 裡的「連接器」，負責和某一個 Server 建立一對一的通道，把需求翻譯成 MCP 的標準語言。
• MCP Server（伺服器）：一支輕量程式，代表某個外部工具或資料源（例如公司知識庫、資料庫、GitHub），對外用標準格式「掛牌」說明自己能提供哪些能力。

而每一支 MCP Server，對外主要提供三種能力：

• 工具（Tools）：可被 AI 調用、實際執行動作的函式，例如「查一筆訂單」「寄一封信」。
• 資源（Resources）：可被讀取的資料內容，例如檔案、文件、資料庫紀錄。
• 提示範本（Prompts）：預先寫好的提示詞或工作流程，讓常用任務能一鍵套用。

實例走一遍：請 AI 幫你摘要最新郵件

先認識這場戲的角色：

• 使用者：下指令的人，這裡以想摘要信件的用戶為例。
• AI Agent（前端）：你直接互動的介面，內含 MCP Client，負責跟 LLM 溝通、並透過 MCP Client 連上外部系統，這裡以 EgentHub 為例。
• LLM：AI Agent 的大腦，負責理解指令、判斷該調用哪個工具、最後組織回覆，這裡以 Gemini、GPT、Claude 等為例。
• 外部系統：真正存放資料或提供功能的系統，透過 MCP Server 對外掛牌提供能力，這裡以 Gmail 為例。

流程走一遍：

1. 使用者下指令：你在 EgentHub 輸入「請讀取我最新的郵件並幫我摘要」。
2. AI Agent 打包送出：EgentHub 把 System Prompt、User Prompt，連同「可用工具清單」（其中就包含 Gmail 的 MCP 工具）一起打包，送給 LLM。
3. LLM 判斷要用工具：LLM 分析後發現，這得讀取真實信件、不是它記憶裡的資料，於是輸出一個 tool_call，指名要用 Gmail 的讀信工具。
4. 呼叫 MCP Client：EgentHub 收到 tool_call，交給內部的 MCP Client 執行。
5. 轉送給 MCP Server：MCP Client 依 MCP 的標準格式，把 tool_call 轉送給 Gmail 的 MCP Server。
6. 翻成實際 API 呼叫：MCP Server 把標準化的 tool_call，翻譯成真正的 Gmail API 呼叫。
7. 外部系統回傳結果：Gmail 讀出最新郵件、回傳原文，MCP Server 再用 JSON-RPC 標準格式，把結果交回 MCP Client，並送回 EgentHub。
8. 結果再送 LLM：EgentHub 把這份工具結果，當成 tool_result 訊息再次遞給 LLM。
9. LLM 組織回覆：LLM 消化收到的郵件內容，用自然通順的語言寫成一段摘要。
10. 呈現給使用者：EgentHub 把摘要顯示給你，任務完成。

白話總結：整段流程裡真正被標準化的，其實只有「MCP Client 對接 MCP Server」那一段。換句話說，哪天你改成要 AI 讀行事曆、查 CRM，前面的下指令、打包、組織回覆通通不用動——只要對方工具同樣備好自己的 MCP Server，EgentHub 就能用同一套方式接上去。這，正是統一接頭的威力。

MCP 和 Function Call 是什麼關係？

看到這裡，讀過《Function Call 是什麼？》的你，可能會冒出一個疑問：這跟 Function Call 不是很像嗎？

其實兩者是互補，而不是彼此取代。Function Call 是 AI 的「手腳」，讓模型能自己判斷「該不該動用工具、又該用哪一個」；但 Function Call 本身並沒有規定工具長什麼樣、該怎麼接進來，所以每多接一個新工具，開發者依舊得各自客製一番。

MCP 補上的，正好是這一塊。它是工具與 AI 之間的標準接口——如果說 Function Call 是「伸手去拿工具」的那個動作，MCP 就是「讓所有工具都裝上同一款插座、手一插就能用」的那套標準。

一句話記住：Function Call 與 MCP，前者是動作，後者是規格。

對企業的價值，與不能忽略的風險

站在企業角度，MCP 帶來的改變其實很具體：

• 一次開發、到處可用：把公司系統包成一支 MCP Server，之後任何支援 MCP 的 AI 應用都能接上，不必為每個工具重寫一遍。
• 生態互通、可自由組合：市面上現成的 MCP Server（雲端硬碟、資料庫、專案管理工具）能像積木一樣拼起來，快速擴張 AI 的能力邊界。
• 維護成本更低：接口統一之後，改版與除錯都集中在同一處，長期維運的負擔明顯減輕。

當然，統一接口也帶出新的功課。一旦 AI 能透過 MCP 直接碰到企業內部系統，安全與治理的重要性就被放大：哪些 Server 值得信任、每支 Server 能拿到多大的存取權限、又該怎麼擋掉惡意指令，全都需要一套清楚的控管機制。方便與風險常常是一體兩面，這也是企業導入時最該謹慎設計的地方。

結語：當 AI 開始萬物互通

MCP 的意義，在於它把「AI 與外部世界的連接」，從各自為政的客製工程，推進成一套人人遵循的共通標準。接口一旦統一，AI 就能像插上 USB-C 那樣，輕鬆連上企業的各種系統與資料，真正變成融入工作流程的協作夥伴。

但一如這個系列反覆提醒的：連接能力越強，越需要人類在權限與安全上守住關口。如何在「開放互通」與「安全可控」之間拿捏平衡，正是企業讓 AI 真正落地時，那道最關鍵的考題。

也因此，MCP 是打造可擴充 AI Agent 的關鍵拼圖之一。作為台灣企業級的 AI Agent 管理平台，EgentHub 完整支援 MCP 串接：一方面讓 AI Agent 能一鍵接上公司內部的資料庫、ERP 與各式系統，另一方面透過完整的權限管理機制，確保每一次串接都在可控範圍內部署、監控與管理，讓企業放心把 AI Agent 從概念變成日常可信賴的戰力。