MCP 與 JSON Schema 是什麼關係？2026 AI Agent Tool Calling 數據結構完整解析

MCP 與 JSON Schema 各管哪一層

Model Context Protocol（MCP）定義客戶端與 Server 之間怎麼發現工具、怎麼發 JSON-RPC 請求、怎麼返回結果。它不發明一種新的類型系統——工具參數用 JSON Schema（Draft 2020-12 子集）寫在每個 Tool 的 inputSchema 字段裏。JSON Schema 在這裏的角色是「工具契約」：告訴客戶端與模型，searchInvoices 需要 startDate、endDate，status 只能是 draft/sent/paid/void。

JSON Schema 在 Agent 棧裏還出現在別處：Structured Output 約束模型最終答覆；OpenAI Responses API 的 text.format.json_schema 管抽取結果；REST OpenAPI 描述 HTTP body。MCP inputSchema 只管工具入參。搞混這三者，會出現「模型輸出 Schema 校驗過了，但 tools/call 參數仍缺鍵」——因爲約束的是不同 hop。

規範層面，MCP Tool 對象包含 name、description、inputSchema（及可選 outputSchema）。Server 在 tools/list 響應裏暴露清單；客戶端緩存後注入模型上下文。2026-07-28 無狀態 MCP 把 Session 從協議層拿掉，但不會自動校驗 arguments——inputSchema 是聲明，執行層仍要 JSON.parse + Schema 校驗。詳見Stateless MCP 解析。

Tool Calling 數據流：從模型到 MCP Server

一條典型的 Remote MCP Agent 鏈路可以拆成五步：

1. 客戶端 tools/list（或緩存）拿到 Tool 定義，含 inputSchema。
2. 把 Tool 列表轉成模型 API 格式（OpenAI tools[]、Anthropic tools[] 等），Schema 字段名可能從 inputSchema 映射成 parameters。
3. 模型返回 tool_calls / tool_use，arguments 通常是JSON 字符串（個別 SDK 已 parse 成對象）。
4. 客戶端 JSON.parse arguments，組裝 MCP JSON-RPC tools/call，params 含 name 與 arguments 對象。
5. MCP Server 再次校驗 arguments，執行業務邏輯，返回 result.content（常爲 text JSON）。

容易出錯的點集中在第 3→4 步：模型把數字寫成字符串、漏 required、或工具名與 Schema 版本不一致（客戶端緩存了舊 tools/list）。無狀態 MCP 下每次請求自帶 _meta，但 arguments 形狀仍依賴你在第 2 步餵給模型的 Schema 是否與 Server 一致。

下面是一個 tools/call 請求體示例（2026-07-28，省略 HTTP 頭）：

{
  "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"
    }
  }
}

inputSchema 與 OpenAI parameters 的對照

MCP 與 OpenAI function calling 在 Schema 字段上高度同構，但工程細節有差：

同一份發票搜索工具，MCP 側寫法：

{
  "name": "searchInvoices",
  "description": "Search invoices by date range and status",
  "inputSchema": {
    "type": "object",
    "properties": {
      "startDate": { "type": "string", "format": "date" },
      "endDate": { "type": "string", "format": "date" },
      "status": {
        "type": "string",
        "enum": ["draft", "sent", "paid", "void"]
      }
    },
    "required": ["startDate", "endDate"],
    "additionalProperties": false
  }
}

OpenAI strict tool 側寫法（注意 required 需列全 properties 才能通過 strict 編譯）：

{
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "description": "Search invoices by date range and status",
    "strict": true,
    "parameters": {
      "type": "object",
      "properties": {
        "startDate": { "type": "string", "format": "date" },
        "endDate": { "type": "string", "format": "date" },
        "status": {
          "type": "string",
          "enum": ["draft", "sent", "paid", "void"]
        }
      },
      "required": ["startDate", "endDate", "status"],
      "additionalProperties": false
    }
  }
}

Anthropic 把同構 Schema 放在 input_schema；Gemini function declaration 用 parameters 對象。差異主要在字段名與 strict 子集，不是業務字段本身。維護一份 canonical Schema（YAML/JSON 文件），CI 裏生成 MCP Tool、OpenAI tool、OpenAPI 三種外殼，比三處手寫更不易 drift。

2026 各棧：OpenAI、Anthropic、Gemini、MCP

2026 年沒有「一個 Schema 走天下」，但 Tool Calling 數據結構的共同點越來越多：arguments 是 JSON object，Schema 基於 JSON Schema 子集。粗粒度對照：

Structured Output（模型最終 JSON 答覆）與 Tool arguments 是兩條 hop。站內AI Structured Output 教程講前者；AI 生成 JSON 錯誤指南講四層錯誤 taxonomy。Agent 集成要把「答覆 Schema」和「工具 Schema」分文件、分版本號，避免改了一個 tool 卻誤傷 extraction Schema。

DeepSeek V4-Flash 等仍偏 json_object 輸出，Tool strict 在 Beta；Remote MCP 則無狀態化後更適合水平擴展，但 arguments 校驗責任不變。Apple 生態裏同一 Swift 函數可同時服務 App Intent、Foundation Models Tool 與 MCP——見Apple AI Agent 與 JSON。

一份 Schema 三處複用

推薦在倉庫裏維護單一真相源（Single Source of Truth），例如 schemas/search-invoices.schema.json：

1. 生成 MCP Tool 的 inputSchema（直接嵌入或 $ref）。
2. 生成 OpenAI/Anthropic tool 定義，strict 模式下自動補全 required。
3. 生成 OpenAPI requestBody，供 Server 調下游 HTTP 時複用同一字段表。

版本策略：Breaking 改字段時 bump schema_version 或 tool name（如 searchInvoices_v2），並縮短 tools/list 緩存 TTL。無狀態 MCP 下客戶端常緩存 Tool 列表；stale Schema 會把錯誤 shape 寫進 arguments——這在Stateless MCP 文FAQ 裏強調過。

outputSchema（MCP 可選）描述工具返回 JSON 形狀，便於客戶端或模型解析 result；與 inputSchema 對稱，但 2026 實踐裏 many Server 仍返回自由 text，由調用方 Schema 校驗。若你控制 Server，給結構化 result 也掛 Schema，Agent 重試邏輯會更穩。

校驗鏈路與 JSONVue 實操

每個 hop 建議固定三步：parse → Schema → 業務規則。

1. 模型 arguments 字符串：JSON.parse，失敗則記錄 raw 與 tool_call id。
2. 對照 inputSchema（或 strict parameters）做 Draft 2020-12 校驗，輸出 path/keyword。
3. 業務 gate：日期範圍合法、status 與權限匹配、外鍵存在。

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

延伸閱讀：AI Structured Output 教程、Stateless MCP 解析、AI 生成 JSON 錯誤指南、DeepSeek V4-Flash JSON。

常見問題 FAQ

總結與下一步

MCP 與 JSON Schema 的關係可以概括成：MCP 用 JSON Schema 描述工具入參（inputSchema），用 JSON-RPC 傳輸 tools/call；JSON Schema 本身還服務 Structured Output 與 OpenAPI。2026 Agent Tool Calling 的數據結構主線是「一份 canonical Schema → 多 API 外殼 → 每 hop parse + Schema + 業務校驗」。

下一步：對照 tools/list 與 OpenAI tools[] 是否同源 Schema；用 JSONVue 驗一條完整 tools/call 往返。需要協議細節讀 Stateless MCP；需要模型輸出形狀讀 Structured Output；需要失敗分層讀 JSON 錯誤指南。