Agent 編排篇、Agent Runtime 篇與 Tool Gateway 篇一路把「協定內部」留白給本篇；這裡正式展開——MCP 到底是什麼、不是什麼，以及它解掉的那個爆炸。

《LLM 應用編排與 Agent 模式》在講「為何需要標準協定」的那一節立下一個動機：當你有 M 個 Agent／應用、要接 N 個工具或資料源時，若每一對整合都各自客製，成本會逼近 M × N——每加一個新工具，所有應用都要重接一次。那一篇刻意只講「為什麼需要標準協定」，把角色分工、傳輸方式、訊息格式全都外推給協定專篇。《Agent Runtime 後端服務設計》把 MCP 當成「工具如何被發現與呼叫」的一個抽象邊界；《Tool Gateway、權限與安全邊界》則提到「MCP server 可以是安全強制點的一個落點」。三篇留下的同一塊空白，就是本篇要填的：協定本身長什麼樣。

Model Context Protocol（MCP）是一套開放協定，用來標準化「一個承載 LLM 的應用程式」與「外部工具、資料源」之間的溝通。它由 Anthropic 於 2024 年底提出並開源，隨後被主流 AI 應用與各大廠採用。它的核心承諾只有一句話：

因為名字裡有「Context」、又常和 Agent 一起出現，MCP 很容易被誤解成別的東西。先用一張表把邊界劃清楚，後面各章才好對號入座：

記住這四條「不是」，就抓住了 MCP 的定位：它是工具／資料側的互通協定，一層很薄、但省掉大量重工的標準。

MCP 把「應用 ↔ 工具」拆成三個角色。搞懂這三者的拓樸與那條 1:1 的線，後面所有訊息往返才對得上位置。

MCP 的架構刻意分成三個角色，各司其職。最容易搞混的是 Host 與 Client——它們常在同一個行程裡，但職責不同：

它們的拓樸是「一個 Host、多個 Client、多個 Server」，而每個 Client 只綁一個 Server——這條 1:1 的線是整個模型的關鍵：

1 Host : N Client : N Server，其中 Client ↔ Server 恆為 1:1。要多接一個工具源，就多開一個 Client 連一個 Server，Host 其餘部分不動。

對接 Agent Runtime 篇：那篇的 Agent Runtime 就是 Host 的一種形態。那篇把「工具如何被發現與呼叫」留成一個抽象邊界，如今可以填上具體答案——runtime 作為 Host，會為每個要用的工具源建立一個 Client，透過 1:1 session 去發現與呼叫工具。至於角色之間實際傳什麼訊息、怎麼交握，是第 4、5 節的事。

Server 能提供的東西不只「工具」。MCP 把能力分成三種 primitive，分野不在功能，而在「誰決定何時用它」。

一個 MCP Server 可以暴露三類能力，稱為 primitives。很多人只知道 tools，但另外兩者同樣重要。三者最本質的差異，是控制權——由誰主導它在什麼時候被用：

把控制權當成一條光譜就清楚了：tool 由模型主導、resource 由應用主導、prompt 由使用者主導。這條光譜也決定了它們各自的 discovery 與呼叫方法：

三者共用同一個「list → 取用」的動態發現節奏（第 5 節會看到），但控制權不同，因此在產品 UI 上的呈現也不同：工具由模型自動選、資源由應用附掛、prompt 由使用者點選。

角色與能力有了，還缺「訊息走哪條線」。MCP 的編碼固定是 JSON-RPC 2.0，傳輸則有兩種標準選擇——外加一個已被淘汰的舊選項。

MCP 所有訊息都以 JSON-RPC 2.0 編碼（UTF-8）。JSON-RPC 只有三種訊息型態，貫穿後面所有交握與呼叫：

「有沒有 id」是判讀一則 MCP 訊息的第一個線索：有 id 要配對回應，無 id 是單向通知。第 5 節拆解器裡的「notification」樣本就是一則 initialized，把它的 id 加回去，分類立刻改判。

JSON-RPC 決定了「訊息長什麼樣」，但這些位元組實際透過什麼管道流動，是 transport 的事。截至撰稿時（2026 年中，最新規格版本 2025-11-25），MCP 定義了兩種標準 transport：

這一章把前面的角色、primitive、transport 串成一條時間線——也就是 Agent Runtime 篇留白的「工具如何被發現與呼叫」，在此正式展開，並由本章的拆解器 Demo 把訊息攤開來看。

一條 MCP session 從建立到用上工具，會依序走過三個階段。三階段用同一套 JSON-RPC 訊息，但目的不同：

① 交握（Initialization）。Client 送出 initialize request，帶上自己支援的 protocolVersion、capabilities 與 clientInfo；Server 回以自己的版本、能力與 serverInfo。雙方就此協商出這條 session 要用哪個協定版本、彼此支援哪些能力（例如 Server 宣告 tools.listChanged 表示工具清單變動時會發通知）。協商成功後，Client 再送一則 notifications/initialized 通知，正式開始正常操作。能力是「談」出來的、不是硬編碼的——這正是協定能向前相容演進的關鍵。

② 探索（Discovery）。Client 送 tools/list（可帶分頁 cursor），Server 回傳一份工具清單，每個工具含 name、description 與 inputSchema。重點是：Client 事前完全不需要知道有哪些工具——是 Server 在執行期把自己「自我描述」出來的。工具清單還可能中途變動，Server 會發 notifications/tools/list_changed，Client 再重新 tools/list。

③ 呼叫與回寫（Invocation）。模型從清單裡挑一個工具、填好參數後，Client 送 tools/call（name + arguments）；Server 執行完把結果回寫在 result.content[]（可含 text／image／resource 等內容塊），並以 isError 標示成敗。Client 把這份結果交回 Host，餵給模型生成最終回答——這一步正好接上 Agent Runtime 篇那台狀態機的 tool_calls → running 回寫。

把三個階段放到一條時間線上，就是一條 session 最小可用的往返：

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: initialize（版本＋capabilities）
    S-->>C: result（版本＋capabilities）
    C->>S: notifications/initialized
    C->>S: tools/list
    S-->>C: result（name＋inputSchema）
    C->>S: tools/call（name＋arguments）
    S-->>C: result.content[] 或 error

看第三條線 notifications/initialized——它沒有回箭頭，因為 notification 無 id、不等回應；其餘每一條請求都恰好配一條同 id 的回應。交握兩則、通知一則、每種 primitive 各一次 list 往返，是這條 session 的固定開銷。

這些訊息長什麼樣、合不合法、能不能用，全都寫在那一小段 JSON 裡。下面的 Demo 讓你直接改那段 JSON，它會真的把訊息拆開判給你看：

如果這條流程不用 MCP、改成自建 Function Calling 會怎樣？大致是：沒有 initialize 那次版本／能力協商（版本相容全靠你自己約定）、沒有 tools/list 這一步——工具清單與 schema 被寫死在應用程式碼裡，模型能用什麼在編譯期就定死了；tools/call 則退化成你自訂格式的一次內部函式呼叫，換一個應用就得整套重寫。少掉的那兩步（協商與發現），正是 MCP 換來的「互通性」。完整取捨留待第 6 節。

既然模型端本來就會 function calling，為什麼還要 MCP？答案不在「功能」，而在「互通性」與「你願不願意背那層抽象」。

先講清楚一件最常被誤會的事：MCP 不取代 function calling，兩者在不同層。模型「決定呼叫某個工具、吐出參數」這件事，仍然是 function calling；MCP 標準化的是它外圍的一切——工具如何被描述、如何被發現、透過什麼管道傳輸、結果如何回寫。可以說：function calling 是模型的能力，MCP 是承載這個能力的互通協定。

把「自建」與「MCP」並排，差異集中在四點：

MCP 用「一次協定開銷」換「跨應用的互通與生態重用」；自建用「零抽象」換「綁死單一應用」。這不是誰對誰錯，是規模與邊界的取捨。

兩個相鄰邊界順帶釐清，避免混淆：其一，MCP server 可以是 gateway 的一個落點——你能把 allowlist、authz、審計實作在 server 這一側，讓它同時是協定端點與強制點；但那是「安全政策擺哪裡」的工程選擇，政策原則本身見 Tool Gateway 篇，本篇只負責協定介面。其二，MCP 是工具／資料側的協定互通，與 LLM Gateway（模型側的路由、fallback、成本、semantic cache）是兩條正交的線——一個管「工具怎麼接」，一個管「模型怎麼選」。

收尾把 MCP 放回整個 Agent 後端版圖：它在系列裡的座標、常見誤區，以及一組能直接搬去面試的選型與問答。

走到這裡，Agent 後端的地圖已經完整。MCP 在其中的座標，正好把 Agent 編排、Agent Runtime、Tool Gateway 三篇串起來：

真正落地時，第一個要決定的是 transport／部署形態，判準很直接：

生態現況（截至撰稿時）：官方提供多語言 SDK，社群與各大廠已有大量現成 server；要接第三方能力時，先找有沒有現成 MCP server，往往比自己刻更快。