系列：【MCP 與 FastMCP 實戰】#01（共 4 篇）｜難度：L2-進階

前置知識：知道 LLM／AI 代理（agent）大概在幹嘛、看得懂 JSON 與 client/server 的基本概念。

一句話說明

MCP（Model Context Protocol，模型上下文協定）是一套「讓 AI 應用程式跟外部工具、資料溝通」的標準介面——你可以把它想成「AI 世界的 USB-C」：不管是哪個模型、哪個工具，只要兩邊都講 MCP，就能插上就用，不用每次都重寫一套對接程式碼。

這篇文章不是教你「怎麼寫一個 MCP server」（那是後面幾篇的事），而是先讓你看懂 MCP 在講什麼、名詞對應到什麼、以及 2026-07-28 這版規格改了哪些會影響你驗收的重點。因為當 AI 幫你生一個 MCP 專案時，你要能判斷它寫的東西是不是「這個時代的寫法」。

MCP 要解決什麼問題

在 MCP 出現前，「讓 LLM 用外部工具」大致是這樣做的：

• 你在程式裡自己定義一堆 function，寫一份 JSON schema 描述它們，塞進 API 呼叫裡（這就是 function calling）。
• 每換一個模型供應商、每接一個新工具，就得重寫一次對接。
• N 個 AI 應用 × M 個工具＝ N×M 份膠水程式碼，維護到崩潰。

MCP 的目標就是把這件事標準化：工具那一端寫成一個 MCP server（只寫一次），AI 應用那一端當 MCP client（只實作一次協定），兩邊透過統一的訊息格式溝通。於是 N×M 變成 N＋M。

一句話翻譯：**function calling 是「這一次對話裡臨時告訴模型有哪些 function」；MCP 是「把工具打包成一個可重複插拔的標準服務」。** 兩者不衝突——MCP server 提供的工具，最後常常還是以 function calling 的形式餵給模型。

三方架構：Host、Client、Server

MCP 的官方說法是 client-host-server 架構。三個角色一定要分清楚，不然後面看 code 會很亂：

關鍵心智模型：一個 Host 可以開很多個 Client，每個 Client 對應一個 Server（1:1）。這樣設計是為了安全邊界——一個 server 看不到整段對話，也「看不進」其他 server。

        ┌─────────────── Host（例如 Cursor）───────────────┐
        │   ┌────────┐        ┌────────┐        ┌────────┐  │
        │   │Client A│        │Client B│        │Client C│  │
        └───┴───┬────┴────────┴───┬────┴────────┴───┬────┴──┘
                │ (1:1)           │ (1:1)           │ (1:1)
           ┌────▼─────┐      ┌────▼─────┐      ┌────▼─────┐
           │ Server:  │      │ Server:  │      │ Server:  │
           │ 檔案系統 │      │  GitHub  │      │ Postgres │
           └──────────┘      └──────────┘      └──────────┘
Code language: CSS (css)

訊息流：底層是 JSON-RPC

MCP 的訊息用 JSON-RPC 2.0 格式（一種很單純的「請求／回應」JSON 約定）。一個最小的「列出這個 server 有哪些工具」請求長這樣：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}
Code language: JSON / JSON with Comments (json)

翻譯：「用 JSON-RPC，這是第 1 號請求，我要呼叫 tools/list 這個方法。」

Server 回：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "tools": [
      { "name": "search_files", "description": "在專案裡搜尋檔案", "inputSchema": { "...": "..." } }
    ]
  }
}
Code language: JSON / JSON with Comments (json)

翻譯：「第 1 號請求的結果，這是一個『完整』結果（resultType: complete，2026-07-28 新增，等等會講），我有一個叫 search_files 的工具。」

✅ 必看懂：method 是動詞（tools/list、tools/call、resources/read…），id 用來把請求跟回應配對，result 是結果、error 是出錯。看到這幾個關鍵字就知道這是 MCP 訊息。

三大核心原語：Tools / Resources / Prompts

MCP server 能提供三種東西，官方叫「原語（primitives）」。分辨它們的最快方法是問「誰來決定什麼時候用它」：

一句話記法：

• Tool = 動詞：模型自己判斷要不要呼叫（會做事、可能改變外部狀態）。
• Resource = 名詞：像檔案，用 URI（例如 file:///project/README.md）指名，唯讀。
• Prompt = 範本：使用者主動挑來用，例如在輸入框打 /review。

📌 知道就好：Tools 是「model-controlled」不代表沒人管——規格明確要求應用程式應該保留 human in the loop，讓使用者能否決工具呼叫。所以你在 Host 上看到「是否允許這個工具執行？」的確認框，是符合規格的正確設計。

2026-07-28 新版規格：改了什麼、為什麼要在意

先搞清楚版本輩分。MCP 的規格版本用「日期」當版號，一路是：

2024-11-05 → 2025-03-26 → 2025-06-18 → 2025-11-25 → 2026-07-28（最新）

2026-07-28 是目前最新修訂版，它相對於前一版 2025-11-25 做了一次「大手術」。如果你之前讀的是 2025-06-18 那份廣為流傳的規格，會發現很多名詞對不上——這很正常，因為中間改很大。以下是對 Vibe Coder 最有感的幾項：

1. 協定變「無狀態（stateless）」，拿掉 initialize 握手

舊版：client 連上 server 要先做一次 initialize / notifications/initialized 握手，交換一次協定版本與能力，之後靠一個 Mcp-Session-Id session 維持狀態。

新版：握手沒了、session 沒了。每一個請求都自帶協定版本與能力，放在 _meta 欄位裡：

"_meta": {
  "io.modelcontextprotocol/protocolVersion": "2026-07-28",
  "io.modelcontextprotocol/clientInfo": { "name": "cursor", "version": "1.0" },
  "io.modelcontextprotocol/clientCapabilities": { "...": "..." }
}
Code language: JavaScript (javascript)

翻譯：「每次請求我都重新報一次：我講哪版協定、我是誰、我支援哪些能力。」

為什麼改：無狀態的協定比較好做水平擴展（server 可以隨便換一台機器處理，不用記得你上次講了什麼），也更適合雲端部署。相容性重點：跨版本協商靠新的 server/discover RPC——server 必須實作它來公告自己支援哪些協定版本與能力；版本不合會回 UnsupportedProtocolVersionError。

2. 訂閱改成 subscriptions/listen 一條長連線

舊版用 HTTP GET endpoint 加上 resources/subscribe/unsubscribe 收變更通知。新版統一成一條 subscriptions/listen 的長連線 POST，client 主動 opt-in 想收哪幾種通知（toolsListChanged、resourcesListChanged…）。同時移除了 SSE 斷線重送——連線斷了，進行中的請求就當作丟失，client 要用新的 request ID 重發。

3. 「多輪往返請求」（MRTR）取代 server 主動發問

舊版 server 想反過來問 client（例如要 client 幫忙 sampling、elicitation、給 roots）是靠 server 主動送請求。新版改成：server 回一個 resultType: "input_required" 的 InputRequiredResult，把「我還需要什麼」寫在 inputRequests；client 補齊資料後重試原本那個請求。這也是為什麼每個 result 現在都有 resultType 欄位（"complete" 或 "input_required"）。

相容性提醒：**舊版 server 回的 result 沒有 resultType，新版 client 必須把它一律當成 "complete"**。

4. 砍掉／降級了一批舊功能

• 移除 ping、logging/setLevel、notifications/roots/list_changed。log 等級改成每個請求用 _meta 帶。
• Roots、Sampling、Logging 三個功能被標記為 deprecated（棄用中）：還能用，但新專案不該再採用。官方建議：用工具參數/資源 URI 取代 Roots；直接接 LLM 供應商 API 取代 Sampling；用 stderr 或 OpenTelemetry 取代 Logging。
• 舊的 HTTP+SSE transport 正式歸類為 deprecated，請改用 Streamable HTTP。
• 實驗性的 tasks 從核心協定移到官方擴充（extension）。

為什麼要升級：無狀態化讓部署更簡單、擴展更容易，MRTR 讓「server 需要 client 補資料」的流程更乾淨，而砍掉 session/握手降低了實作複雜度。但代價是跟舊版不相容——所以你會在同一個生態裡同時看到新舊寫法，這正是驗收時要盯的地方。

MCP vs REST API vs function calling：怎麼取捨

重點取捨：MCP 不是要取代 REST。很多 MCP server 內部其實就是去打一支 REST API，只是外面包了一層「模型看得懂、能被 client 統一發現與協商」的標準殼。小專案只有一兩個工具時，直接 function calling 反而更省事。

🚩 紅旗：AI 生 MCP 專案時要警覺什麼

1. 🚩 還在寫 initialize 握手、Mcp-Session-Id、resources/subscribe：這是 2025 舊版寫法。若你要的是 2026-07-28，這代表 AI 參考了過時資料，要請它改成 stateless + server/discover + subscriptions/listen。
2. 🚩 把 Resource 當 Tool 用來「執行動作」：Resource 是唯讀資料。看到某個「resource」會寄信、改資料庫，就是搞混原語了。
3. 🚩 新專案還在用 Roots / Sampling / Logging：這三個已 deprecated，新專案不該採用，AI 若主動加進來要質疑。
4. 🚩 result 沒處理 resultType：client 端若完全沒有「遇到 input_required 就補資料重試」的邏輯，碰到需要多輪往返的 server 會直接壞掉。
5. 🚩 宣稱「MCP 取代 REST/function calling」：這是行銷式誤解，通常代表對取捨沒想清楚。

看不懂某段是不是舊寫法時，直接問 AI：「這段 MCP code 是對應哪個版本的規格？2026-07-28 的話有沒有用到已經被移除或棄用的方法？」

Vibe Coder 驗收檢查點

• [ ] 能用一句話說出 Host / Client / Server 各是誰、Client 跟 Server 是不是 1:1。
• [ ] 給你一段功能描述（「查資料庫」「提供 README 內容」「/review 指令」），能正確歸類成 Tool / Resource / Prompt。
• [ ] 看到一段 MCP JSON，能指出 method、id、result 分別在幹嘛。
• [ ] 能講出 2026-07-28 至少 2 項「跟舊版不相容」的變更（stateless 無握手、server/discover、subscriptions/listen、resultType、Roots/Sampling/Logging 棄用，任選）。
• [ ] 驗收動作：把 AI 生成的 server 骨架貼給它問「這是 2026-07-28 規格嗎？有沒有用到 deprecated 功能？」，看它能不能自我盤點。

看不懂就這樣問 AI

「用白話解釋 MCP 的 Host、Client、Server 三個角色，各舉一個真實例子，我是初學者。」

「我手上這份 MCP server code 是哪一版規格？跟 2026-07-28 最新版比，有哪些方法已經被移除或標記 deprecated？請列表對照。」

「幫我判斷這個需求該做成 Tool、Resource 還是 Prompt，並說明理由：______」

下一篇預告：#02 會進到 FastMCP——用 Python 幾行程式碼就把一個函式變成 MCP server，並帶你讀懂它生出來的 code 對應到本篇哪些概念。