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 没有一个简单的办法判断，出问题时排查链路很长。