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 错误指南。