MCP 是什麼？Model Context Protocol、JSON-RPC、AI Agent 與大模型工具調用完整指南

先給結論：MCP（Model Context Protocol）不是另一種 Function Calling，也不是一個模型。它是 AI 應用（Host）和外部工具行程（MCP Server）之間的開放協議，報文是 JSON-RPC 2.0。大模型仍然走各家的 Tool Calling / Function Calling；Host 把 tools/list 譯成模型的 tools 陣列，再把模型的 tool_calls 譯成 tools/call。三層疊在一起，才是 2026 年常見的 Agent 工具呼叫。

這篇按 2026 年 9 月 7 日寫。當前規範是 2026-07-28：協議層無會話、無 initialize 握手，每條請求自帶 _meta，發現能力用 server/discover。本站 8 月的《Agent JSON 資料流》仍用舊版 initialize 舉例；讀這份指南時以 7 月規範為準。遷移細節見《MCP 2026 遷移指南》。

MCP 是什麼

Model Context Protocol 是一套給 AI 應用發現、讀取和呼叫外部上下文的開放標準。Anthropic 在 2024 年 11 月釋出，後來交到 Agentic AI Foundation 開源治理。它只規定「上下文怎麼交換」，不規定你用哪家模型、怎麼編排多步 Agent、怎麼寫業務程式碼。

可以記成 USB-C：插座形狀統一，插頭後面接硬碟、顯示器還是電源，協議不管。MCP 統一的是 Host ↔ Server 的插座；後面接檔案系統、GitHub、內部訂單 API，還是本站這種 JSON 校驗服務，都是 Server 自己的事。

協議分兩層：資料層是 JSON-RPC 2.0（方法、參數、錯誤碼、通知）；傳輸層是怎麼把這些 JSON 運過去——本機用 stdio，遠端用 Streamable HTTP。換傳輸不換報文形狀。這就是為什麼除錯 MCP 時，先分清「信封是 JSON-RPC，業務載荷也常是 JSON」。

Host、Client、Server

規範裡的三角，不要和「客戶端 / 伺服器」口語混用：

• Host：使用者開啟的 AI 應用。它建立 Client、把工具 Schema 餵給模型、執行前做授權與校驗、把結果寫回對話。
• Client：Host 內部的一個連線物件。一臺 Server 對應一個 Client。VS Code 同時連檔案系統和 Sentry，執行時就是兩個 Client。
• Server：提供上下文的程式。可以和 Host 同機（stdio），也可以在別的機器上（Streamable HTTP）。「Server」指角色，不指必須有一個公網域名。

模型不在這個三角里。GPT-5.5、Claude 4.8、Gemini 3.7 看見的是 Host 翻譯好的 tools 陣列，看不見 JSON-RPC，也看不見 Mcp-Session-Id（2026-07-28 已經去掉會話頭）。把模型直接「對接 MCP」是產品話術；工程上永遠隔著一層 Host。

JSON-RPC 2.0 報文怎麼讀

JSON-RPC 是一種用 JSON 做遠端過程呼叫的約定，比 REST 更接近「呼叫一個函式」。MCP 選它，是因為方法名穩定（tools/list、tools/call）、請求/響應/通知三分法清楚，而且對模型友好——整份信封都是 JSON。

一次 tools/call（規範 2026-07-28）看起來像這樣。注意：沒有握手、沒有 session 頭，版本和客戶端身份在 _meta 裡，任何 Server 例項都能處理這一幀。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "validate_json",
    "arguments": {
      "payload": {"orderId": "A-1001", "total": 42.5},
      "schemaId": "order.v1"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "json-toolbox-host",
        "version": "1.0.0"
      }
    }
  }
}

成功響應同樣是 JSON 信封。業務結果在 result.content 裡，常見 type: "text"，文字本身又可能是一段 JSON——外層是協議，內層是載荷。除錯時先看 id 能否對上請求，再對內層做 Schema 校驗。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "{\"valid\":true,\"schemaId\":\"order.v1\"}"
      }
    ]
  }
}

錯誤走 JSON-RPC 的 error 物件：code、message、可選 data。2026-07-28 把「資源不存在」從 MCP 自定義 -32002 改成標準 -32602（Invalid Params）。客戶端若寫死舊錯誤碼，會漏判。通知（notification）沒有 id，也不等響應，例如工具列表變化。

Tools、Resources、Prompts

Server 能對外暴露三類原語。Agent 日常用得最多的是 Tools；另外兩類常被忽略，卻能少浪費一輪模型猜測。

工具定義的核心是 name、description 和 inputSchema。inputSchema 是 JSON Schema（2026-07-28 起按 2020-12，根仍須 type: "object"，允許 oneOf / $ref / $defs）。可選的 outputSchema 約束返回形狀。Host 幾乎是一對一把 inputSchema 填進模型 API 的 parameters / input_schema。

{
  "name": "validate_json",
  "title": "Validate JSON",
  "description": "Check a JSON payload against a named schema. Returns valid and errors.",
  "inputSchema": {
    "type": "object",
    "additionalProperties": false,
    "properties": {
      "payload": { "type": "object", "description": "Already parsed JSON object, not a raw string" },
      "schemaId": { "type": "string", "description": "Stable schema id such as order.v1" }
    },
    "required": ["payload", "schemaId"]
  }
}

Resources 適合「先讀再想」：把 schema://order.v1 讀進上下文，比讓模型在對話裡背一份 200 行 Schema 便宜。Prompts 適合團隊固化的開場白。Roots、Sampling、Logging 在 2026-07-28 已棄用：工作區路徑改用工具參數或資源 URI；Server 不要再向 Host 要一次補全；日誌走 stderr 或 OpenTelemetry。

和 Tool Calling 怎麼疊

三個名字經常被寫成一回事。資料流上它們不在同一層——上一篇《Agent JSON 資料流》拆過每一跳，這裡只記對映：

Function Calling 是早期 OpenAI 的名字；Tool Calling 是後來更通用的叫法（Claude tools、Gemini Function Calling、OpenAI Tools API）。對開發者是同一套：Host 把 Schema 發給模型，模型返回帶 JSON 參數的呼叫，Host 執行後再把 JSON 結果塞回對話。

MCP 不替代這一層。沒有 MCP 時，Host 在行程內調本機函式也完全合法。有了 MCP，工具變成可發現、可跨行程、可換 Host 複用的 Server。企業 Agent 幾乎總是兩層疊用；指令碼和演示可以只用 Tool Calling。

對映時有兩處容易踩坑：模型 API 常把 arguments 做成字串，MCP 的 params.arguments 是物件；以及 tools/list 的 name 必須原樣傳給模型和 tools/call，不要在中間改成「更友好」的別名。校驗應發生在真正 tools/call 之前，見《Tool Calling 與 JSON Schema 驗證》。

一次完整工具呼叫

使用者說：「用 order.v1 校驗這段訂單 JSON。」按 2026-07-28，端到端是：

1. Host → Server：server/discover（可快取）確認對方有 tools；或直接發後續請求，版本不對再重試。
2. Host → Server：tools/list 拿到帶 inputSchema 的清單，響應可帶 ttlMs / cacheScope。
3. Host → 模型：把清單對映成 tools[].parameters（仍是 JSON Schema）。
4. 模型 → Host：tool_calls，name 為 validate_json，arguments 多為字串化 JSON。
5. Host 校驗：JSON.parse 後按 inputSchema 驗；失敗則把錯誤寫成 tool 結果，不碰真實 Server。
6. Host → Server：tools/call，arguments 為物件，_meta 帶協議版本。
7. Server → Host：result.content；Host 必要時再按 outputSchema 驗一遍。
8. Host → 模型：role: tool 的 JSON 字串，模型再寫成給使用者的話，或繼續下一輪工具。

使用者自然語言
    │
    ▼
Host ──JSON Schema──► LLM Tool Calling
    │                      │
    │                      ▼
    │                 arguments JSON
    ▼                      │
MCP JSON-RPC ◄──── 校驗透過才 tools/call
    │
    ▼
result JSON ──► tool message ──► 模型最終答覆

遠端傳輸時，HTTP 頭還要帶 MCP-Protocol-Version、Mcp-Method、Mcp-Name，且必須與 body 一致，否則 Server 應拒。負載均衡可以只看頭、不拆 JSON。本機 stdio 沒有這些頭，但 JSON-RPC 方法名相同。

2026-07-28 你要記住的

7 月規範是 MCP 上線以來最大的一次修訂，7 月 28 日已作為正式版釋出。對「MCP 是什麼」只記下面幾條；要不要改 Server 程式碼，仍看遷移文的決策樹。

• 無握手、無協議會話：initialize / initialized 和 Mcp-Session-Id 已去掉。每條請求自包含。應用狀態請自己用 basket_id 這類顯式參數串起來，不要指望傳輸層幫你記。
• 發現改走 server/discover：可選，但能一次拿到支援的版本、capabilities、serverInfo。列表結果帶 ttlMs，不必靠長 SSE 才能知道工具變了。
• Schema 升到 JSON Schema 2020-12：輸入根仍是 object，可用組合與引用；不要自動解外部 $ref。輸出 Schema 不再限定為 object。
• 棄用 Roots / Sampling / Logging：一年視窗內方法還在；新 Server 不要再實現 Sampling 向 Host 要補全。
• Extensions：Tasks、MCP Apps 是官方擴充套件，不是核心必做。長任務用 task handle + tasks/get，不要自己發明會話。

仍跑 2025-11-25 的 Host / Server 會繼續用 initialize。混連時看雙方協商出的版本，不要把這篇的無握手報文打給舊 Server。選型與生態見《2026 MCP Server 排名》。

現在該怎麼用

1. 先畫三層，再寫程式碼：模型 API 的 Tool Calling、Host 編排、MCP Server。只做指令碼就停在前兩層；要跨 IDE 複用工具，再寫 Server。
2. 用官方 SDK，不要手寫 JSON-RPC 幀：@modelcontextprotocol/sdk 以及各語言官方包已經處理發現、傳輸和錯誤碼。手寫 SSE 或私有欄位，是遷移文裡「必須改程式碼」的典型原因。
3. 把 inputSchema 寫成能獨立校驗的契約：additionalProperties: false、required、列舉、長度上限。模型會漏欄位、會把數字寫成字串。執行前用同一份 Schema 擋一次。
4. 本機 stdio，遠端 Streamable HTTP：個人除錯不必上 HTTP。團隊共享、多客戶端、要過閘道器時再上遠端傳輸，並加 OAuth / 最小許可權。
5. 列表要快取，結果要裁：尊重 ttlMs；工具返回不要把堆疊原文灌回模型。視窗再大，髒 JSON 也會汙染下一輪——見《1M Token 上下文視窗》。
6. 落地前在瀏覽器裡對樣例：把 inputSchema、正例 / 反例 arguments、Server 返回樣例存成 JSON，用本站校驗和 Diff。資料不上傳。這和測 REST 契約同一習慣。

常見問題 FAQ

總結

MCP 是 2026 年 Agent 的工具插座：JSON-RPC 2.0 在 Host 和 Server 之間搬運發現與呼叫；大模型側仍然是 Tool Calling；JSON Schema 是兩邊共用的契約。它不是模型，不是框架，也不替代 OpenAPI。當前規範 2026-07-28 把會話從協議裡拿掉了，請求必須自包含；Tools / Resources / Prompts 三類原語沒變。

讀這份指南只為建立正確的分層。每一跳的位元組形狀見資料流文，舊 Server 要不要改程式碼見遷移文，裝哪些現成 Server 見評測文。動手前先把 Schema 和樣例 JSON 在本機校驗過——模型可以換，欄位名和 required 不該變。