当前位置: 首页 > news >正文

JSON-RPC 2.0 与 MCP 协议:从消息格式到进程通信 大模型MCP

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

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

成员名类型是否必需描述
jsonrpcString协议版本,固定为"2.0"
methodString被调用方法的名称
paramsArray / Object结构化参数,可为数组或对象
idString / Number / Null客户端生成的唯一标识符,用于关联响应

请求示例:

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

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

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

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

成员名类型是否必需描述
jsonrpcString固定为"2.0"
resultAny条件成功时返回,包含调用结果
errorObject条件失败时返回,包含错误信息
idString / Number / Null与对应请求的id值一致

resulterror互斥,同一响应中只能出现其一。

成功响应:

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

错误响应:

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

1.2 预定义错误码

错误码消息含义
-32700Parse error服务端接收到无效的 JSON
-32600Invalid Request发送的 JSON 不是有效请求对象
-32601Method not found请求的方法不存在
-32602Invalid params方法参数无效
-32603Internal errorJSON-RPC 内部错误
-32000 至 -32099Server error预留用于自定义服务器错误

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

方法方向用途
initialize客户端 → 服务器协商协议版本和双方能力
notifications/initialized客户端 → 服务器通知服务器客户端已就绪(无id
tools/list客户端 → 服务器获取服务器提供的工具列表
tools/call客户端 → 服务器调用指定的工具

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

图理解:

🖥️ MCP 服务器💻 MCP 客户端🧠 模型 (LLM)👤 用户🖥️ MCP 服务器💻 MCP 客户端🧠 模型 (LLM)👤 用户阶段一:初始化(建立会话)阶段二:用户发起请求模型推理:1. 理解意图2. 判断需要调用工具3. 选择工具并生成参数阶段三:协议通信(JSON-RPC 2.0 over stdio)模型推理:根据工具执行结果生成最终回复阶段四:后续交互(重复阶段二至三)initialize (id:0)响应 (id:0)notifications/initialized (无id)tools/list (id:1)响应 (id:1): 工具列表发送自然语言指令"帮我跟小王说声你好"调用工具请求{name: "send_message",arguments: {to: "小王", text: "你好"}}tools/call (id:4){name: "send_message",arguments: {to:"小王", text:"你好"}}响应 (id:4){content: [{type:"text",text:"消息已发送"}]}返回自然语言结果"已向小王发送问候"

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

http://www.jsqmd.com/news/1338449/

相关文章:

  • 同城工地应急发电机出租怎么选?道路抢修与户外发电机租赁服务商参考指南 - 优质品牌商家
  • 不同分子量PLA/PLLA对微球降解动力学的影响规律及机制解析
  • Godot物理游戏开发:阻尼振荡器与可破坏地形的实现与优化
  • 从“跑通Demo”到“工程落地”:三层框架破解技术工具“无法解释为什么”困境
  • 从零构建飞书小程序Demo:环境配置、核心开发与实战指南
  • 成都靠谱的商务租车口碑如何选?2026年本地租车公司实力对比分析 - 优质品牌商家
  • Unity资源逆向与Mod制作:UABEA工具核心功能与实战指南
  • PNP晶体管工作原理、关键参数与经典应用电路全解析
  • UE5蓝图实战:零代码实现程序化地下城生成与动态关卡流送
  • 2026年明渠流量仪源头厂家推荐指南:6大关键指标助你精准择优 - geo交流
  • Kali部署Vulfocus遇“服务器内部错误”排查与解决指南
  • 2026年扬州市多分类垃圾房电话甄选指南:3个**渠道推荐 - geo交流
  • C语言数组最值查找:线性遍历与分治算法详解
  • XUnity.AutoTranslator:游戏实时翻译插件从安装到实战全攻略
  • XUnity.AutoTranslator终极指南:5分钟解锁Unity游戏自动翻译
  • OpenClaw:从零部署AI自治智能体,实现自动化工作流
  • BIRTV 2026 · 北京
  • 淘宝客网站怎么建设:新手必看实战指南,从零搭建高转化推广平台
  • 2026年人血管内皮生长因子受体(VEGFR)ELISA试剂盒公司推荐:3个甄选考量维度 - geo交流
  • CTF Python逆向实战:从混淆代码到Flag获取的五步方法论
  • TDengine在工业物联网中的时序数据处理实战
  • 酒店智能改造方案的分期投资策略_现金流与风险管控
  • 抖音动态水印怎么去除?2026合规去水印方法与风险提醒 - 办公小帮手
  • 57.4亿元市场背后的技术变革:工业具身智能机器人从实验室走向制造现场的关键路径
  • 2026年耐用的加厚浮桥定制严选指南:3个步骤轻松甄选 - geo交流
  • Spring BeanCreationNotAllowedException:容器销毁阶段Bean创建异常解析与解决方案
  • AI图片变清晰接口总报错?从鉴权到超时的完整排错路径
  • 2026年如何甄选优质导电PBT厂家电话?这份优选指南值得收藏 - geo交流
  • 前端性能优化:visibilitychange事件实现页面智能资源调度
  • Unity Vuforia AR安卓打包全流程检查清单(2024版)