JSON-RPC 2.0 与 MCP 协议：从消息格式到进程通信 大模型MCP

JSON-RPC 2.0 与 MCP 协议：从消息格式到进程通信

一、JSON-RPC 2.0：一种轻量级的 RPC 协议

JSON-RPC 2.0 是一种无状态、轻量级的远程过程调用协议。它使用 JSON 作为数据交换格式，不绑定特定的传输层，可运行于 HTTP、WebSocket、TCP Socket 及标准输入输出（stdio）等多种环境。

1.1 三种核心消息类型

JSON-RPC 2.0 定义了三种消息对象。

请求对象用于发起一次调用，包含以下成员：

成员名类型是否必需描述
jsonrpcString是协议版本，固定为"2.0"
methodString是被调用方法的名称
paramsArray / Object否结构化参数，可为数组或对象
idString / Number / Null是客户端生成的唯一标识符，用于关联响应

请求示例：

{"jsonrpc":"2.0","method":"subtract","params":[42,23],"id":1}

通知对象是一种特殊请求，不包含id成员。服务端收到后必须不返回任何响应。

{"jsonrpc":"2.0","method":"update","params":[1,2,3]}

响应对象由服务端在处理完非通知请求后返回：

成员名类型是否必需描述
jsonrpcString是固定为"2.0"
resultAny条件成功时返回，包含调用结果
errorObject条件失败时返回，包含错误信息
idString / Number / Null是与对应请求的id值一致

result和error互斥，同一响应中只能出现其一。

成功响应：

{"jsonrpc":"2.0","result":19,"id":1}

错误响应：

{"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found"},"id":1}

1.2 预定义错误码

错误码消息含义
-32700Parse error服务端接收到无效的 JSON
-32600Invalid Request发送的 JSON 不是有效请求对象
-32601Method not found请求的方法不存在
-32602Invalid params方法参数无效
-32603Internal errorJSON-RPC 内部错误
-32000 至 -32099Server error预留用于自定义服务器错误

1.3 批量调用

JSON-RPC 2.0 支持在单个消息中发送请求对象数组。服务端必须以数组形式返回对应的响应列表。

批量请求：

[{"jsonrpc":"2.0","method":"sum","params":[1,2,4],"id":"1"},{"jsonrpc":"2.0","method":"subtract","params":[42,23],"id":"2"},{"jsonrpc":"2.0","method":"foo","id":"3"}]

批量响应：

[{"jsonrpc":"2.0","result":7,"id":"1"},{"jsonrpc":"2.0","result":19,"id":"2"},{"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found"},"id":"3"}]

二、MCP：基于 JSON-RPC 2.0 的模型上下文协议

MCP（Model Context Protocol）是在 JSON-RPC 2.0 基础上构建的应用层协议，用于标准化 AI 应用（客户端）与外部系统（服务器）之间的交互。

2.1 MCP 对 JSON-RPC 2.0 的扩展与约束

MCP 完全遵循 JSON-RPC 2.0 的消息格式，但对其中的id字段施加了更严格的约束：

  • 请求对象的id不能为null，必须是字符串或整数
  • 同一会话中，请求方发出的每个id必须唯一
  • 错误响应中的error.code必须是整数

2.2 标准化的方法与参数结构

MCP 通过预定义一系列method名称及其params结构，将通用的 JSON-RPC 协议转化为具有明确语义的交互规范。主要方法包括：

方法方向用途
initialize客户端 → 服务器协商协议版本和双方能力
notifications/initialized客户端 → 服务器通知服务器客户端已就绪（无id）
tools/list客户端 → 服务器获取服务器提供的工具列表
tools/call客户端 → 服务器调用指定的工具

三、MCP 基于 JSON-RPC 2.0 的通信流程

图理解：

🖥️ MCP 服务器💻 MCP 客户端🧠 模型 (LLM)👤 用户🖥️ MCP 服务器💻 MCP 客户端🧠 模型 (LLM)👤 用户阶段一：初始化（建立会话）阶段二：用户发起请求模型推理：1. 理解意图2. 判断需要调用工具3. 选择工具并生成参数阶段三：协议通信（JSON-RPC 2.0 over stdio）模型推理：根据工具执行结果生成最终回复阶段四：后续交互（重复阶段二至三）initialize (id:0)响应 (id:0)notifications/initialized (无id)tools/list (id:1)响应 (id:1): 工具列表发送自然语言指令"帮我跟小王说声你好"调用工具请求{name: "send_message",arguments: {to: "小王", text: "你好"}}tools/call (id:4){name: "send_message",arguments: {to:"小王", text:"你好"}}响应 (id:4){content: [{type:"text",text:"消息已发送"}]}返回自然语言结果"已向小王发送问候"

一次完整的 MCP 客户端-服务器交互包含以下四个步骤。

3.1 初始化

客户端发送initialize请求，包含协议版本、自身能力及客户端信息。

{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{"tools":{}},"clientInfo":{"name":"my-client","version":"1.0.0"}}}

服务器返回协商结果：

{"jsonrpc":"2.0","id":0,"result":{"protocolVersion":"2025-06-18","capabilities":{"tools":{}},"serverInfo":{"name":"GreetingServer","version":"1.0.0"}}}

3.2 初始化完成通知

客户端收到成功的初始化响应后，发送一个无id的通知，表明自身已准备就绪。服务器无需回复。

{"jsonrpc":"2.0","method":"notifications/initialized"}

3.3 工具发现

客户端请求获取服务器提供的所有工具：

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

服务器返回工具列表，每个工具包含名称、描述及其输入参数的 JSON Schema 定义。

3.4 工具执行

客户端发起工具调用：

{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"HelloTool","arguments":{"value":"World"}}}

服务器执行并返回结果：

{"jsonrpc":"2.0","id":4,"result":{"content":[{"type":"text","text":"Hello, World!"}]}}

四、stdio 传输机制的具体实现

MCP 定义了两套传输机制，其中 stdio 用于本地进程间通信。

4.1 进程模型

客户端（如 Claude Desktop、Cursor）将 MCP 服务器程序作为子进程启动。操作系统在父子进程之间建立三条管道：

  • stdin（标准输入）：客户端向其中写入数据，服务器从中读取数据
  • stdout（标准输出）：服务器向其中写入数据，客户端从中读取数据
  • stderr（标准错误）：服务器输出日志信息，客户端可读取用于调试

4.2 消息界定规则

stdio 传输对消息格式有以下规定：

  • 每条 JSON-RPC 消息必须为单独一行，以换行符（\n）结尾
  • 消息体（JSON 字符串）内部不允许包含未转义的换行符
  • 所有消息使用 UTF-8 编码

4.3 消息流向

  • 客户端 → 服务器：通过服务器的stdin发送 JSON-RPC 请求或通知
  • 服务器 → 客户端：通过服务器的stdout返回 JSON-RPC 响应或通知
  • 日志信息：通过stderr输出，不影响主消息通道

4.4 生命周期管理

  • 启动：客户端以子进程方式启动服务器程序，可通过命令行参数传递配置
  • 关闭：客户端关闭stdin流以通知服务器退出；若服务器未及时响应，客户端可强制终止进程

五、关于“RPC”命名的说明

JSON-RPC 2.0 虽名为“远程过程调用”，但其核心语义与物理距离无关。以下从两个维度进行说明。

5.1 “远程”指逻辑空间而非物理距离

在计算机科学中，“远程”指跨越地址空间。本地函数调用在同一个进程的内存空间内执行，而 RPC 调用涉及独立的进程，被调用方的内存空间对调用方不可见。在 stdio 场景下，两个进程运行于同一台物理机器上，但在逻辑层面属于“远程”调用。

5.2 RPC 的核心是模拟函数调用

RPC 协议与通用消息队列的区别在于其强绑定于函数调用范式：

  • 请求中必须包含method（函数名）和params（实参）
  • 响应中必须包含result（返回值）或error（异常）
  • id机制将响应精准匹配至对应的请求，模拟同步函数调用的语义

5.3 历史传承

JSON-RPC 继承自 XML-RPC（1998 年），后者最初设计用于 HTTP 协议下的远程服务器调用。JSON-RPC 保留了“RPC”命名，尽管其应用场景已扩展至本地进程通信。该协议本身不绑定传输层，同一套消息格式可运行于 stdio、HTTP、WebSocket 或 TCP Socket 之上，传输层更换不影响上层调用逻辑。