MCP的通信方式是分场景来采取的如果MCP Server和MCP Client都是本地部署此时MCP协议的通信方式主要通过标准输入输出stdio来实现通信如果MCP Server单独作为一个HTTP服务来运行此时MCP的通信方式是通过Streamable HTTP来实现的但是不论MCP采取的是哪一种通信方式底层的消息传输的格式都是JSON-RPC2.0一、MCP底层的消息格式---JSON-RPC2.0在介绍通信方式前先来介绍一下MCP底层的消息传输的格式因为无论使用哪一种通信方式底层的消息格式都是不变的都是以JSON-RPC2.0的格式来进行消息的传输为什么MCP底层的消息格式会用JSON-RPC2.0呢MCP 的核心流程是由 MCP Client 发起调用、MCP Server 处理并返回数据本质属于远程过程调用RPC。要完成这套跨端远程调用交互就需要一套标准化的消息传输规范来承载交互数据也就是图中的 JSON-RPC 消息模板。JSON-RPC2.0就是现成的足够轻量的RPC消息模版以JSON格式易读易调试且许多编程语言都能实现不论是Python、Java或者是TypeScript写的格式都一样这样也省去了引入序列器的功夫每条消息就是一个JSON对象如下面的例子// 请求消息Client - Server { jsonrpc: 2.0, id: 1, // 请求 ID用于匹配响应 method: tools/call, // 调用的方法名 params: { name: take_screenshot, // 工具名 arguments: {url: https://example.com} } } // 响应消息Server - Client { jsonrpc: 2.0, id: 1, // 对应请求的 ID result: { content: [{type: image, data: ...base64...}] } }JSON-RPC2.0只关注消息的格式不关心消息的传输方式MCP协议在这个的基础上实现了两种通信方式二、本地通信方式stdio(标准输入输出)stdio是MCP Client和MCP Server在本地部署的情景下使用的通信方式原理是Client启动时将Server作为一个子进程顺带着启动了此时Client通过标准输入的形式向Server发送请求然后Server在以标准输出的格式返回结果因为Client和Server都是本地部署此时着两个进程间的通信可以通过操作系统的“通道”来实现通信即可这样避免的做网络提高的数据的传输和接收的效率通道这里的通道可以理解为操作系统为这两个进程提供的一个先进先出的内存缓冲区Client发送一条JSON请求就往这个内存缓冲区添加一条JSON信息然后Server再从这个缓冲区获取这个JSON信息当Server处理完请求返回JSON信息时也会往缓冲区添加JSON信息然后Client那边也从缓冲区读即可三、远程通信方式Streamable HTTP当MCP Server以HTTP服务单独远程部署时此时如果Client想调用Server服务此时就需要走网络此时远程通信下MCP推荐的通信方式是Streamable HTTP传统HTTP的痛点传统标准短连接 HTTP 采用一问一答交互模型客户端发起单次请求服务端返回唯一对应响应完成交互后连接便会释放。且原生 HTTP 协议本身不支持服务端主动向客户端推送数据若要获取服务端实时变更、执行进度等信息客户端只能采用定时轮询的低效方案。 同时传统 REST 风格的接口设计思路会为每一类业务操作单独定义独立接口路径。而 MCP 场景存在高频双向交互、频繁工具调用、实时日志与进度推送等需求这套传统 HTTP 模式存在明显短板无法适配 MCP 的通信诉求。而SSE能实现服务端持续想客户端推送消息的功能但是不支持客户端随时发送新请求双方交互受限而Streamable HTTP就是为了解决传统HTTP的痛点其核心设计是用单个HTTP端点通常是/mcp同时处理请求和响应解释单个HTTP端点整个MCP远程通信不分功能拆分接口所有的交互动作全部复用的都是同一个路由地址一般是http://xxx:port/mcp这里的xxx是指IP地址port是指端口号此时不管你要进行什么操作不管是查询工作列表还是工具调用或者其他操作此时不需要另外设计一大堆新的接口这些全部统一请求到/mcp接口解释同时处理请求和响应同时处理请求和响应的核心就是建立一个双向流单个端点双向接收和发送消息底层的实现机制Client向/mcp发送一个post请求请求头带上流式标识建立一条持久HTTP长连接流1.客户端流的写入发送请求此时客户端这边就可以往这条HTTP连接流中写入JSON-RPC请求报文携带唯一id如查询资源、调用工具等源源不断地发送给服务端2.服务端流的读出和写入返回响应主动推送时间服务端这边则在同一个连接流上做两件事情1.接收到客户端的请求后处理请求返回对应id的JSON-RPC格式的响应2.此时客户端不需要主动发送新请求服务端可主动下发一些通知例如工具的执行进度、日志、实时事件推送等这样就方便让客户端清楚任务的执行进度了四、HTTP SSE 双端点通信方案HTTP SSE 双端点方案是 MCP 早期版本2024-11-05 规范采用的远程传输方案在 2025 年 3 月的规范更新里被标记为 deprecated仍然保留向后兼容。为什么要替换原因是架构上有一个小尴尬Client 向 Server 发请求要走 POST 端点Server 向 Client 推数据要走另一条 SSE 长连接端点同一个对话被拆成了两条通道。这带来的具体问题是状态管理复杂比如 Client POST 了一条消息之后网络突然断了那条消息到底被处理了没、SSE 流会不会推回结果Client 没有一个简单的办法判断出问题时排查链路很长。