MCP 通信消息格式之 JSON-RPC 2.0 协议

一、背景介绍

MCP 中 Client 与  Server 间使用 JSON-RPC 2.0 作为通信消息格式。JSON-RPC 是 RPC（远程过程调用）的一种具体实现，RPC 是一种通信范式，其核心目标是屏蔽网络细节，使远程调用如同本地调用般简单，并可基于多种底层网络协议（如 TCP/HTTP）实现。常见的 RPC 框架有 gRPC、Dubbo 和 Thrift。
JSON-RPC 2.0 是一种使用 JSON 格式的轻量级远程过程调用 (RPC) 协议，与 RPC 有以下区别：
特性RPC（通用）JSON-RPC协议类型抽象概念，有多种实现RPC 的一种具体实现数据格式二进制（如 Protobuf）、文本等默认使用 JSON传输协议任意（TCP/HTTP/UDP 等）通常基于 HTTP/HTTPS 或 WebSocket跨语言兼容性依赖具体实现（如 gRPC）天然支持（JSON 是通用标准）性能二进制协议通常更高文本协议，性能较低使用场景高性能内部服务（如 gRPC）Web API、前后端交互、脚本语言二、消息类型

1. 请求（Request）

1. {
2.   "jsonrpc": "2.0",
3.   "method": "方法名",
4.   "params": {"参数名": "值"} | ["值 1", "值 2"],  // 对象或数组
5.   "id": "唯一ID"                             // 可选（通知请求可省略）
6. }

复制代码

jsonrpc : 必须为 "2.0"。
method: 调用的方法名（字符串）。
params: 参数（可省略），支持对象（命名参数）或数组（位置参数）。
id: 请求标识符。
2. 响应（Response）

成功响应：

1. {
2.   "jsonrpc": "2.0",
3.   "result": "返回值",
4.   "id": "对应请求 ID"
5. }

复制代码

错误响应：

1. {
2.   "jsonrpc": "2.0",
3.   "error": {
4.     "code": -32601,
5.     "message": "Method not found",
6.     "data": "额外错误信息"  // 可选
7.   },
8.   "id": "对应请求 ID"      // 若请求无 ID，则为 null
9. }

复制代码

标准错误码：
CodeMessage说明-32700Parse errorJSON 解析失败-32600Invalid Request请求格式不符合规范-32601Method not found方法不存在-32602Invalid params参数无效-32603Internal error服务端内部错误-32000Server error（自定义）业务级错误（范围：-32000 至 -32099）3. 通知（Notification）

无 id 的请求，客户端不返回响应：

1. {
2.   "jsonrpc": "2.0",
3.   "method": "log_event",
4.   "params": {"event": "user_login"}
5. }

复制代码

三、主要特点

（1）简单轻量：协议设计简洁，消息格式简单。
（2）语言无关：基于 JSON，几乎所有编程语言都支持。
（3）传输层无关：可在 HTTP、WebSocket、TCP 等多种传输协议上使用。
（4）支持通知（不需要响应的请求）。
（5）支持批量请求。
四、使用建议

1. 请求与响应设计

（1）严格校验 jsonrpc 字段：确保值为 "2.0"，避免版本混淆。
（2）明确参数类型：在文档中声明 params 是对象还是数组。
（3）处理通知请求：无 id 的请求不返回响应，节省带宽。
2. 错误处理

（1）标准化错误信息：错误响应中，data 字段可酌情附加调试详情（如堆栈跟踪），但要注意信息安全。
（2）自定义错误码：业务错误使用 -32000 到 -32099 范围。
3. 安全性

（1）字段过滤：避免在响应中返回敏感数据（如密码）。
（2）传输加密：使用 HTTPS 防止中间人攻击。
（3）限流与鉴权：通过 HTTP Headers（如 Authorization）实现身份验证。
4. 性能优化

（1）批量请求（Batch）：支持单次传输多个请求（减少 HTTP 开销）：

1. [
2.   {"jsonrpc": "2.0", "method": "sum", "params": [1, 2], "id": "1"},
3.   {"jsonrpc": "2.0", "method": "notify", "params": ["event"]}
4. ]

复制代码

（2）压缩数据：启用 Gzip 压缩 JSON 内容。
五、常见问题

1. 批量请求是否必须按顺序返回响应？

规范未强制要求顺序，但建议保持请求与响应顺序一致。
2. JSON-RPC 是否可以作为 RESTful 通信消息格式？

JSON-RPC 和 RESTful 是两种不同的 API 设计风格，虽都可基于 HTTP，但设计理念与适用场景差异显著，具体如下：
特性JSON-RPCRESTful设计哲学基于动作（Action）的远程调用基于资源（Resource）的状态操作HTTP 方法使用通常只用 POST（所有请求发到同一端点）使用 GET/POST/PUT/DELETE 等URL 设计单一端点（如 /api/jsonrpc）资源路径（如 /users/{id}）数据格式固定 JSON 结构（含 method 和 params）灵活（JSON/XML，通常无固定结构约束）典型用例复杂业务逻辑（如计算、事务）CRUD 操作（如用户管理）以删除一个用户为例：
JSON-RPC 需向统一端点（URL）发送如下消息格式：

1. {
2.   "jsonrpc": "2.0",
3.   "method": "deleteUser",
4.   "params": {"id": 123},
5.   "id": 1
6. }

复制代码

RESTful 则只需发起一个 DELETE /users/123 请求。
综上所述，笔者认为 JSON-RPC 不适合作为 RESTful 的通信消息格式，原因有二：其一，调用方式不同，JSON-RPC 通过 method 参数调用指定方法，RESTful API 则依赖 HTTP 方法（如 GET/POST）和 URL 路径标识调用方法；其二，支持的协议范围不同，REST API 仅适配 HTTP 协议，JSON-RPC 支持常见网络协议，如 HTTP、TCP 等。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！