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 定义了三种消息对象。

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

请求示例：

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

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

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

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

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

成功响应：

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

错误响应：

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

1.2 预定义错误码

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 协议转化为具有明确语义的交互规范。主要方法包括：

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

图理解：

一次完整的 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 之上，传输层更换不影响上层调用逻辑。