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)

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

jsonrpc : 必须为 "2.0"

method: 调用的方法名(字符串)。

params: 参数(可省略),支持对象(命名参数)或数组(位置参数)。

id: 请求标识符。

2. 响应(Response)

成功响应:

{
  "jsonrpc": "2.0",
  "result": "返回值",
  "id": "对应请求 ID"
}

错误响应:

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32601,
    "message": "Method not found",
    "data": "额外错误信息"  // 可选
  },
  "id": "对应请求 ID"      // 若请求无 ID,则为 null
}

标准错误码:

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

3. 通知(Notification)

无 id 的请求,客户端不返回响应:

{
  "jsonrpc": "2.0",
  "method": "log_event",
  "params": {"event": "user_login"}
}

三、主要特点

(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 开销):

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

(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 结构(含 methodparams灵活(JSON/XML,通常无固定结构约束)
典型用例复杂业务逻辑(如计算、事务)CRUD 操作(如用户管理)

以删除一个用户为例:

JSON-RPC 需向统一端点(URL)发送如下消息格式:

{
  "jsonrpc": "2.0",
  "method": "deleteUser",
  "params": {"id": 123},
  "id": 1
}

RESTful 则只需发起一个 DELETE /users/123 请求。

综上所述,笔者认为 JSON-RPC 不适合作为 RESTful 的通信消息格式,原因有二:其一,调用方式不同,JSON-RPC 通过 method 参数调用指定方法,RESTful API 则依赖 HTTP 方法(如 GET/POST)和 URL 路径标识调用方法;其二,支持的协议范围不同,REST API 仅适配 HTTP 协议,JSON-RPC 支持常见网络协议,如 HTTP、TCP 等。

原创作者: zengzuo613 转载于: https://www.cnblogs.com/zengzuo613/p/18931527
### MCP协议的架构概述 MCP(模型上下文协议)是一种用于促进人工智能模型与外部资源之间高效交互的标准协议。该协议的核心目标是实现LLM(大型语言模型)与其他数据源之间的无缝协作[^1]。 #### 协议架构的关键组成部分 MCP协议主要由两个部分构成:MCP服务器和MCP客户端。其中,MCP服务器负责提供对外部资源的数据访问接口和服务功能;而MCP客户端则作为连接器,允许AI模型通过标准化的方式调用这些服务并获取所需的信息[^3]。 #### 通信机制 为了保障双方的有效沟通,MCP采用了基于JSON-RPC 2.0消息传递方式来完成请求与响应的操作流程。这种设计不仅简化了开发难度,还增强了跨平台兼容性和灵活性。此外,在每次会话建立初期都会执行一次能力协商过程,以此确认彼此支持的功能集范围,并据此调整具体行为模式以达到最佳性能表现水平。 虽然无法直接展示一张具体的MCP协议架构图在此处,但可以描述如下结构层次: ```plaintext +-------------------+ | AI Model | +---------+--------+ | (Request) +---------v--------+ | MCP Client | +---------+--------+ | (Communication via JSON-RPC 2.0 & Capability Negotiation) +---------v--------+ | MCP Server | +---------+--------+ | (Data Access / Functionality Provisioning) +---------v--------+ | External Resources| | (Databases, APIs, etc.)| +-------------------+ ``` 上述文字形式描绘出了整个系统的逻辑布局关系,从上至下依次为:运行中的AI模型、与其对接使用的MCP客户程序端口、经由特定传输协议相互联络的目的地——即部署有对应服务实例所在的远程主机上的MCP伺服单元最后到达各类实际存储介质或者业务处理模块所在位置[^2]。 ### 实际应用场景举例说明 在一个典型的应用案例当中,比如利用Claude Desktop工具配合PostgreSQL类型的数据库管理系统来进行查询操作时,正是借助于这套完整的解决方案才得以顺利完成任务需求。这充分体现了MCP对于加强现代智能化软件系统构建过程中不可或缺的重要价值所在。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值