MCP协议使用的消息格式：JSON-RPC 2.0 全解析
一、消息格式概述MCP（Model Context Protocol）在客户端与服务器之间统一采用 JSON-RPC 2.0 作为消息封装格式。所有请求、响应及通知都严格遵循 JSON-RPC 2.0 规范，使通信结构清晰、易于解析与调试。
二、JSON-RPC 2.0 简介JSON-RPC 2.0 是一种轻量、无状态的远程过程调用协议，以 JSON 结构描述 id、method、params 和 result/error 字段，可脱离具体传输层独立使用，天然适配 MCP 的可插拔通道（Stdio、HTTP/SSE 等）。
三、为何 MCP 选择 JSON-RPC 2.0
- 跨语言易实现：JSON 数据结构简单，主流语言均有成熟库。
- 双向对等：同一连接内既可请求也可响应，适合 MCP 的双向调用场景。
- 与传输层解耦：消息可在本地管道、HTTP 长连接或 SSE 流中透明传递。
- 可扩展：ID 与参数字段不受限，方便增加能力协商、采样等新功能。
四、MCP 中的三类 JSON-RPC 消息
- 请求（Request）：客户端或服务器主动调用方法，例如
mcp.runTool。 - 响应（Response）：对应请求返回
result或error。 - 通知（Notification）：无需响应的单向推送，如进度事件。
五、与 REST 或 GraphQL 的对比
| 特性 | JSON-RPC 2.0 | REST/HTTP | GraphQL |
|---|---|---|---|
| 通信模型 | 方法调用 | 资源导向 | 查询语言 |
| 状态码/错误处理 | 结构化 error 字段 |
HTTP 状态码 | 自定义错误对象 |
| 长连接与流式响应 | 原生支持（双向） | 需升级协议 | 需订阅机制 |
| 适配多工具调用 | 优 | 中 | 中 |
六、开发实践要点
- 为每个请求生成唯一
id，方便追踪多线程或并发场景。 - 在
params中仅传递必要字段，避免上下文过大导致 token 浪费。 - 对
error.code采用统一枚举，便于 LLM 判断重试策略。 - 结合传输层心跳或重连机制，保障长连接稳定性。
