Model Context Protocol (MCP) 是什麼?

Author: ai-dev-diaries

Published Date: 2025-08-19

Model Context Protocol (MCP) 是由 Anthropic 在 2024 年 11 月 25 日提出的開放標準，它透過 JSON-RPC 2.0，為大型語言模型（LLMs）與各式工具與資料來源之間建立了統一、標準化的溝通管道。它被譬喻為「AI 的 USB‑C 埠」，意味著不論是讀取資料、執行功能甚至是套用提示模板，AI 模型只需一套協議，就能順暢操作。

傳統 API 的困境：每個服務一把鑰匙

在過去的軟體開發中，API 就像是打開一個服務的鑰匙。
你要讀取 Google Drive 檔案，就得使用 Google Drive API；要建立 GitHub PR，就得透過 GitHub API。這樣的設計雖然靈活，但也帶來兩大痛點：

整合複雜：每個 API 格式不同，開發者必須學習並維護多份文件。
難以擴展：隨著工具數量增加，維護成本指數成長。

想像你是開發一個「智能助理」：要能查郵件、讀日曆、幫你建待辦清單。用 API 的話，等於你要同時整合 Gmail API、Google Calendar API、Notion API，工作量驚人。

MCP：AI 時代的「USB-C」

MCP 的出現就像 USB-C 一樣 —— 一個統一的協議，讓 AI 模型能夠直接和不同工具溝通，而不用知道背後的細節。

標準化：MCP 用 JSON-RPC 定義資料交換方式，AI 不必針對不同服務寫不同程式碼。
開發更快：只要接好 MCP server，模型就能即時存取服務功能。

換句話說，如果 API 是「每個服務一個插座」，那 MCP 就是「任何裝置都能插的通用接口」。

MCP 與 API 差在哪裡？

功能面	MCP	傳統 API
整合成本	一次接入，多工具可用	每個 API 要各自整合
即時雙向溝通	✅ 支援（類似 WebSocket）	❌ 通常單向請求
動態發現工具	✅ 可以自動探索可用資源	❌ 必須寫死在程式中
延展性	Plug-and-play	需要額外開發
安全性	標準化控制	視 API 而異

MCP 的架構

MCP 採用簡單的 client-server 架構：

MCP Host：AI 主體（如 Claude Desktop、AI IDE）
MCP Client：負責維持與伺服器的一對一連線
MCP Server：提供特定功能（如 Gmail、Slack、資料庫）
本地資料源：檔案、資料庫、本機應用
遠端服務：雲端 API 或 SaaS 工具

實際生活中的比喻與應用範例

比喻：USB-C vs 傳統接口

想像你家有多款不同的 3C 設備，有些用 HDMI、一些用 VGA，有些則是舊型 USB。若每個設備都需要不同線材與接口，就像傳統 API，接線麻煩、易失敗。而 USB‑C 就是一條可以通用多種裝置的線，就像 MCP，一條協議搞定所有連接。

範例①：智能助理找資料

情境：你讓 AI 助理「幫我找到五月份所有跟旅行有關的文件」。

使用 API：AI 必須先了解你的檔案結構、調用雲端硬碟的 API、處理認證、再做搜尋。
使用 MCP：AI 只需呼叫 MCP server 提供的 search_files(query="travel","date_range":"2025‑05") 功能，MCP server 會幫你搞定底層細節並回傳結果。

範例②：協助開發者自動提交程式碼

情境：你想讓 AI 幫你建立 GitHub PR。

傳統方式：需要接入 GitHub API，設定 Auth Token、處理不同分支、create PR。
MCP 方式：透過 MCP 的 GitHub 功能，你只需呼叫 create_pr(repo="my‑repo", branch="feature", title="Add doc")，MCP server 自動處理。