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 判断重试策略。 - 结合传输层心跳或重连机制,保障长连接稳定性。