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

2026 年打開任何一款帶 Agent 的編輯器，設置頁幾乎都會出現 MCP。有人把它當成下一個插件商店，有人把它當成必須會的 AI 協議，也有人把它和 Tool Calling、Function Calling、A2A 混成一個詞。本文用工程定義收束：Model Context Protocol（MCP）是一套開放協議，讓 AI 客戶端發現 Server 上的工具、資源和提示詞，再把它們接到大模型上下文裏。運輸層是 JSON-RPC 2.0；業務層是 tools/list、tools/call 這類方法。它不替代模型，也不等於 Agent——Agent 是循環，MCP 是循環裏「遠程工具怎麼被看見、怎麼被調用」的那一層。讀完你應能分清四件事：協議、信封、運行時、模型選工具。站內已有 Schema 對照、無狀態 Remote、A2A 分層和 Agent 定義，本文做入口，不重複那些深潛。

MCP 是什麼：不是模型，是接工具的協議

最小定義只需要三方：Host（編輯器或 Agent 進程）、Client（Host 裏負責連 Server 的那一端）、Server（暴露工具、資源和提示詞的進程或 HTTPS 端點）。Client 向 Server 要清單，把工具的 name、description 和 inputSchema 注入模型上下文；模型決定調用後，Client 再發一次 tools/call。MCP 管的是發現與調用形狀，不管模型怎麼思考。

把它說成「AI 插件」只對了一半。瀏覽器插件掛在一個宿主上；MCP Server 可以被多個 Client 複用——同一份發票查詢，既可以給 Cursor，也可以給 Claude Desktop 或你自己的編排器。差別不在「能不能調函數」，而在清單和調用信封是否標準化。自己寫 OpenAPI 適配器也能調 HTTP；換一個 Client 就要再寫一遍適配。MCP 把這一層收成協議。官方概念與規範入口見Model Context Protocol 文檔。

時間線上：Anthropic 在 2024 年開源 MCP，2025 年底協議進入 Linux Foundation 的 Agentic AI Foundation（AAIF）。2026 年各家 Host 已經把它當成默認的遠程工具通道，而不是演示功能。協議版本號會出現在請求的 _meta 裏，例如 2026-07-28——那是「雙方都認的語義」，不是「模型變聰明瞭」。和聊天機器人、定時工作流的差別，見AI Agent 是什麼：沒有循環、沒有可校驗的參數形狀，只是聊天；有循環但工具是本地函數，也可以是 Agent，只是沒有標準遠程清單。

JSON-RPC 2.0：MCP 爲什麼用這套信封

MCP 沒有發明一種新的 RPC。它把每一次協議動作放進 JSON-RPC 2.0 信封：jsonrpc、id、method、params，或 error。請求與響應用同一個 id 對齊；通知可以沒有 id。對網關和日誌來說，這比自定義流式幀好拆：先看 method 再看業務。JSON-RPC 本身的字段約定見JSON-RPC 2.0 規範。

method 是協議動詞，不是你的業務函數名。tools/list 列出工具，tools/call 調用其中一個，resources/read 讀資源。業務函數名放在 params.name，參數放在 params.arguments。把 searchInvoices 直接寫成 method 是常見誤讀——那樣就不是 MCP，只是你自己的 JSON-RPC 服務。下面是一次標準的清單請求：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

信封解決三件事：多路複用（並行幾個 id）、錯誤可分類（parse 失敗、方法不存在、業務拒絕）、以及傳輸可替換（stdio 子進程或 Streamable HTTP 都裝同一份 JSON）。它不解決 arguments 對不對。協議認一通合法 JSON-RPC，就可以把缺字段的 arguments 原樣交給 Server。Server 必須自己 parse 並按 inputSchema 校驗。

AI Agent 怎麼用 MCP：發現 → 選工具 → 調用

把演示視頻裏的「智能」拆開，一條接了 MCP 的 Agent 循環仍然只有五步。變的是第 2 步和第 4 步不再綁死本地函數：

用戶目標進入上下文（自然語言 + 可選系統約束）。
Client 對已連接的 MCP Server 發 tools/list，把返回的工具清單轉成模型能讀的 tools / functions。
模型返回 tool_calls（要調哪個函數、arguments 是什麼）或最終文本 / Structured Output。
運行時 JSON.parse arguments，再發 MCP tools/call；把 result 寫成消息寫回上下文。
模型再看結果，決定下一工具或結束。超過 maxSteps、用戶取消或 Schema 失敗則停。

第 4 步的 MCP 請求長這樣。params.arguments 已經是對象，不是字符串。協議版本可以掛在 _meta，方便無狀態路由：

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "searchInvoices",
    "arguments": {
      "startDate": "2026-01-01",
      "endDate": "2026-01-31",
      "status": "paid"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

Agent 的定義不依賴 MCP。本地函數、OpenAPI、自建 HTTP 都能當工具。MCP 的價值是：同一份 Server 能被多個 Host 發現，遠程部署時清單和調用形狀一致。什麼時候該上 MCP、什麼時候本地函數就夠，判斷標準是「有沒有第二個 Client 要複用這批工具」，而不是「看起來更像 2026」。循環本身的工程定義見AI Agent 工作原理。

大模型工具調用：tool_calls 與 tools/call

工程上 Tool Calling 和 Function Calling 是同一機制：模型不直接碰數據庫，而是發出「請調用某某函數、參數如下」的結構化請求。MCP 是下一跳：運行時把這份請求翻譯成 JSON-RPC tools/call。兩跳的字段名經常被混用，對照如下：

這一跳	誰發出	arguments 長什麼樣
模型 Tool Calling	OpenAI / Anthropic / Gemini 等模型 API	多爲 JSON 字符串，嵌在 tool_calls 或 tool_use 裏
MCP tools/call	Host 裏的 MCP Client	params.arguments 是 JSON 對象
下游業務 API	MCP Server 或你的適配層	HTTP JSON body / SQL 參數，形狀應同源 Schema
最終 Structured Output	模型最後一跳	給用戶或下游系統的答案，不是工具入參

模型若決定調用，典型 tool_calls 項長這樣。arguments 仍是字符串。運行時必須先 parse，再放進 MCP params.arguments。不要把字符串原樣塞進 JSON-RPC——那會變成「一個名叫 arguments 的字符串字段」，Server 的 Schema 校驗會直接失敗。

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "arguments": "{\"startDate\":\"2026-01-01\",\"endDate\":\"2026-01-31\",\"status\":\"paid\"}"
  }
}

各家模型 API 的外殼不同：OpenAI 用 tools[].function.parameters，Anthropic 用 input_schema，Gemini 用 function_declarations。MCP 用 Tool.inputSchema。名字不同，canonical Schema 應只有一份。字段怎麼對齊、strict 模式下 required 爲什麼必須寫全，見MCP 與 JSON Schema。最終答覆另走 Structured Output，不要和工具入參共用一個文件。

2026 版圖：本地、遠程、無狀態、A2A

傳輸有兩條主路。本地 stdio：Host 拉起一個子進程，標準輸入輸出走 JSON-RPC，適合本機文件系統、本機數據庫。遠程 Streamable HTTP：Client 對 HTTPS 端點 POST 同一份信封，適合團隊共享的發票、工單、內部 API。遠程不再綁死「先握手再帶 Session ID」；2026-07-28 一帶，請求儘量自描述，網關可以按 method 限流。

無狀態指協議層：任意實例可接任意請求。應用層照樣有數據庫、冪等鍵、用戶身份。把「協議無狀態」理解成「工具可以不校驗」是反的——少了會話緩存，你更不能假設上一輪 tools/list 還有效。緩存了舊清單，就會把錯誤形狀寫進 tools/call。協議細節見無狀態 MCP 與 JSON-RPC。

MCP 也不是多 Agent 協議。一個規劃者把任務交給定價、合規、物流 Agent，走的是 A2A 的 message/send，不是 tools/call。每個專長 Agent 內部仍可用 MCP 調自己的數據庫。協議戰爭的說法多半是錯的：一層對工具，一層對 Agent。對照A2A vs MCP。規範與實現倉庫在MCP GitHub，版本變更以規範倉庫爲準，不要只抄某家 Host 的博客。

落地校驗與 JSONVue 實操

每個 hop 固定三步：parse → Schema → 業務規則。MCP 信封合法，不代表 arguments 合法。模型再聰明，也不替代這三步。

模型 arguments 字符串：JSON.parse；失敗則記下 raw 與 tool_call id，返回可重試的錯誤信封，不要先打下游。
對照 inputSchema / parameters 做 Draft 2020-12 校驗，輸出 path 與 keyword。
業務門：日期範圍、枚舉與權限、外鍵存在。通過後再讓 Server 打下游 API。

聯調時把三份 JSON 並排：模型吐出的 arguments、你發給 MCP 的 params.arguments、Server 實際使用的對象。形狀不一致，問題幾乎總在適配層。瀏覽器裏：JSON 格式化確認 parse；JSON Schema 校驗對 arguments 與 Schema 文件；JSON Diff對比模型 arguments 與 MCP / HTTP body。固定 fixture：valid、missing-field、wrong-enum，CI 與手工排查共用。

延伸閱讀：AI Agent 是什麼、MCP 與 JSON Schema、無狀態 MCP、A2A vs MCP。

常見問題 FAQ

MCP 和 Tool Calling 是一回事嗎？

不是。Tool Calling / Function Calling 是模型 API 這一跳：模型選出函數名和 arguments。MCP 是運行時下一跳：Client 用 JSON-RPC 發現並調用遠程工具。沒有 MCP 也能做 Tool Calling；沒有模型也能寫 MCP Server。把兩跳合成一個詞，日誌就找不到故障在哪一層。

沒有 MCP 能不能做 AI Agent？

能。Agent 的定義是模型在循環裏選行動、運行時執行工具。本地函數、OpenAPI、自建 HTTP 都夠格，只要 arguments 與 result 可校驗。MCP 的價值是清單和傳輸標準化，尤其是遠程、多客戶端時。不要爲了「看起來像 2026」強行加一層。

JSON-RPC 不是老協議嗎，爲什麼 MCP 還用它？

正因爲它老、字段少、到處都能 parse。MCP 需要的是可路由的 method、可對齊的 id、穩定的 error，而不是再發明一套幀。Streamable HTTP 只換運輸，不換信封。嫌 JSON-RPC 不夠「現代」通常解決不了 arguments 填錯。

MCP Server 會不會自動校驗工具參數？

不會。inputSchema 是聲明，協議不替你跑校驗器。Client 和 Server 都應本地 parse + Schema；只信模型或只信對端，缺字段會直接打進業務。分類法見 AI 生成 JSON 錯誤指南。

總結與下一步

MCP 在 2026 年可以概括成：用 JSON-RPC 發現和調用工具，把結果寫回模型上下文。它不是模型，不是 Agent，也不是 A2A。Tool Calling 管模型怎麼選函數；MCP 管運行時怎麼找到並調用遠程工具；JSON Schema 管每一跳的形狀。

下一步：畫出你係統裏的三份 JSON（模型 arguments、MCP params.arguments、下游 body），確認它們是否同源 Schema；用 JSONVue 跑通 valid / 缺字段 / 錯誤枚舉。協議細節讀無狀態 MCP 文，字段對齊讀 Schema 文，多 Agent 讀 A2A 對照。