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 对照。