MCP（Model Context Protocol）

這是 AI 系列第四篇。建議先讀 工具呼叫——MCP 正是把「工具」標準化封裝的協定。

目錄

• 什麼是 MCP？
• 為什麼需要 MCP
• MCP 架構
• 三種能力：Tools / Resources / Prompts
• 傳輸方式
• 實戰範例
• 與 Function Calling 的關係
• 常見問題
• 總結

什麼是 MCP？

MCP（Model Context Protocol，模型上下文協定）是一套開放標準，規範「AI 應用」如何連接「外部工具與資料」。

由 Anthropic 在 2024 年底提出並開源，目標是讓各家 AI 應用與各種工具之間，有一套通用的接法。

一個比喻：AI 世界的 USB-C

沒有 USB-C 前：每個裝置都有自己的接頭，充電線一大堆
有了 USB-C 後：一個標準接口，什麼裝置都能插

沒有 MCP 前：每個 AI 應用接每個工具都要客製
有了 MCP 後：工具做成「MCP server」，任何支援 MCP 的應用都能用

💡 一句話：MCP 是「AI 應用」與「工具/資料」之間的通用插槽。 工具方只要實作一次 MCP server，所有支援 MCP 的 AI 應用（如 Claude Code、Claude 桌面版等）都能直接使用。

為什麼需要 MCP

回顧 工具呼叫：要讓 LLM 用工具，得幫每個工具寫定義、寫串接。問題是——每個 AI 應用、每個工具，兩兩之間都要客製一次。

N×M 問題

       工具A   工具B   工具C   工具D
應用1    ✎      ✎      ✎      ✎
應用2    ✎      ✎      ✎      ✎
應用3    ✎      ✎      ✎      ✎

3 個應用 × 4 個工具 = 12 套客製串接（每個 ✎ 都要各寫一次）

應用變多、工具變多，要寫的串接是「相乘」成長，沒人維護得來。

MCP 怎麼解

把它變成「加法」：每個工具只要做一個標準的 MCP server，每個應用只要實作一次 MCP client。

       MCP 標準介面
應用1 ──┐         ┌── 工具A (MCP server)
應用2 ──┼─ MCP ──┼── 工具B (MCP server)
應用3 ──┘         └── 工具C (MCP server)

工具方寫 1 次 server，應用方寫 1 次 client → N + M，不再是 N × M

好處：

• 工具方：實作一次，所有 MCP 應用都能用。
• 應用方：支援 MCP 一次，整個 MCP 生態的工具都能接。
• 使用者：像裝外掛一樣，把需要的 MCP server 接上即可。

MCP 架構

MCP 採用 Client–Server 架構，有三個角色：

重點

• 一個 Host 可以同時連多個 MCP server（一個接檔案、一個接資料庫、一個接 GitHub…）。
• Client 與 Server 是一對一：每個 server 由一個專屬的 client 負責溝通。
• LLM 透過 Host 看到所有 server 提供的能力，再依 工具呼叫 的方式去用。

三種能力：Tools / Resources / Prompts

MCP server 可以對外提供三種東西（稱為 primitives）：

1. Tools（工具）— 可執行的動作

跟第三篇講的 Function Calling 一樣，是模型可以主動呼叫的功能。例如：「執行 SQL 查詢」「建立 GitHub issue」。由模型判斷何時呼叫。

2. Resources（資源）— 可讀取的資料

server 對外暴露的唯讀資料，例如某個檔案的內容、資料庫的某筆紀錄。它比較像「把資料提供給模型參考」，通常由應用或使用者決定要把哪些資源放進上下文。

3. Prompts（提示範本）— 預設的提示樣板

server 預先準備好的提示模板，讓使用者一鍵套用常見任務。例如一個「程式碼審查」prompt 範本，使用者選了它，就自動帶入一套寫好的指示。通常由使用者主動觸發。

💡 簡單記：Tools 給模型用（執行）、Resources 給模型看（資料）、Prompts 給使用者選（範本）。

傳輸方式

MCP 定義了 client 與 server 之間怎麼傳訊息，主要兩種：

本機工具（讀本地檔案、跑本地指令）→ stdio
遠端服務（雲端 API、團隊共用 server）→ HTTP / SSE

重點

• stdio：最常見於本機工具。例如一個讀寫本地檔案的 MCP server，就跑在使用者電腦上，透過 stdio 跟 AI 應用溝通。
• HTTP/SSE：當 server 部署在遠端、要多人或跨機器使用時採用。

實戰範例

一個檔案系統 MCP server 提供什麼

假設有個「檔案系統」MCP server，它可能對外提供：

Tools（可執行）：
  - read_file(path)      讀取檔案內容
  - write_file(path, content)  寫入檔案
  - list_directory(path) 列出目錄

Resources（可讀資料）：
  - 把某些設定檔暴露成可讀資源

Prompts（範本）：
  - 「整理這個目錄的程式碼風格」範本

從使用者到工具的完整路徑

使用者向一個支援 MCP 的 AI 應用（如 Claude Code）問：「把 config.js 裡的測試帳號移除」
        │
        ▼
Host（該 AI 應用）把任務交給 LLM，並附上可用的 MCP 工具清單
        │
        ▼
LLM 決定呼叫 read_file(path="config.js")        ← Function Calling
        │
        ▼
對應的 MCP Client 透過 stdio 把請求送給檔案系統 MCP Server
        │
        ▼
Server 讀檔，把內容回傳 → Client → Host → 塞回 LLM 上下文
        │
        ▼
LLM 看到內容，決定下一步 write_file(...)         ← 進入下一圈 Agent Loop

可以看到：MCP 並沒有取代 Function Calling，而是幫它把工具標準化、可插拔。

與 Function Calling 的關係

這是最容易混淆的地方，一張表說清楚：

用比喻理解

Function Calling = 你會「點餐」這個動作
MCP            = 一套標準的「外送平台」，讓任何餐廳都能上架、任何 App 都能點

你還是用「點餐」這個動作，但 MCP 讓你能點到所有上架餐廳的菜，
而不必為每家餐廳裝一個專屬 App。

結論：MCP 不取代 Function Calling，而是讓工具的提供與接入變標準化。 模型用工具的方式沒變，變的是「工具從哪來、怎麼接」。

常見問題

問題 1：MCP 和 Function Calling 到底差在哪？

Function Calling 是「模型呼叫工具」的機制；MCP 是「工具如何被提供、如何跨應用連接」的標準。MCP server 提供的工具，最終仍是透過 Function Calling 被模型呼叫。一個是動作，一個是接線標準。

問題 2：MCP 是 Anthropic 專屬的嗎？

不是。MCP 是 Anthropic 提出並開源的開放標準，任何 AI 應用、任何工具方都能實作，不綁定特定廠商。

問題 3：我要用 MCP 一定要會寫程式嗎？

用現成的 MCP server 通常只要在應用設定裡「掛上去」即可（像裝外掛）。要自己做一個 server 才需要寫程式，去實作它提供哪些 Tools / Resources / Prompts。

問題 4：stdio 和 HTTP/SSE 怎麼選？

server 跟應用在同一台機器、處理本地資源 → 用 stdio。server 在遠端、要跨機器或多人共用 → 用 HTTP/SSE。

總結

核心要點

MCP = AI 世界的 USB-C，工具與資料連接的開放標準

關鍵認知：
  ├─ 解決 N×M 問題：工具做一次 server，所有應用都能用
  ├─ 架構：Host（應用）→ Client → Server（工具方）
  ├─ 三種能力：Tools(執行) / Resources(資料) / Prompts(範本)
  ├─ 傳輸：本機用 stdio，遠端用 HTTP/SSE
  └─ 不取代 Function Calling，而是讓工具標準化、可插拔

快速記憶

學習路徑

1. 理解 MCP 是「工具的通用插槽」 ✓
2. 看懂它解決的 N×M 問題 ✓
3. 掌握 Host/Client/Server 架構 ✓
4. 分清 Tools/Resources/Prompts 三種能力 ✓
5. 下一步 → 能力越疊越多，怎麼封裝、怎麼協作？

下一篇

👉 Skills 與進階協作：工具有了、標準有了，最後一篇談怎麼把「做某件事的整套know-how」封裝成 Skills，並用一張全景圖把 LLM、Agent、Tools、MCP、Skills 全部串起來。

建立日期：2026-06-01 最後更新：2026-06-01