6. MCP 协议通常采用什么通信方式？

👔面试官：MCP 协议通常采用什么通信方式？

🙋‍♂️我：MCP 应该是用 WebSocket 吧？因为需要双向通信，Client 发请求、Server 推结果，WebSocket 全双工正好合适。

👔面试官：MCP 并没有用 WebSocket。你想想，MCP 有本地工具和远程工具两种场景，本地场景需要走网络吗？

🙋‍♂️我：本地的话……应该也是走 HTTP 吧，在本机起个服务，Client 通过 localhost 访问？

👔面试官：想复杂了。本地场景用的是 stdio，直接通过进程的标准输入输出通信，根本不需要网络。远程场景才用 HTTP，而且不是 WebSocket，是 SSE。另外不管哪种传输方式，底层消息格式统一用 JSON-RPC 2.0，这一点你也没提到。传输方式和消息格式是解耦的，这个设计是 MCP 灵活性的关键。

看来通信方式这块确实有不少容易搞混的地方，下面我把 MCP 的消息格式和两种传输方式都讲清楚。

💡 简要回答

MCP 支持两种主要的传输方式，分别适用于不同场景。本地场景用 stdio，Client 把 Server 作为子进程启动，通过标准输入输出通信，延迟极低，不用开端口，也没有网络安全问题，我用 Claude Desktop 接本地工具走的就是这种方式。远程场景用 SSE，Server 作为独立的 HTTP 服务部署，多个 Client 可以共享同一个 Server，适合团队统一管理工具服务。2025 年规范还新增了 Streamable HTTP 作为 SSE 的升级替代，更加灵活。不管哪种传输方式，底层消息格式都统一用 JSON-RPC 2.0，传输方式只影响「怎么传」，消息协议本身不变。

📝 详细解析

MCP 的消息格式：JSON-RPC 2.0

在说传输方式之前，先说消息格式，因为不管用哪种传输方式，消息格式都是同一套。

那为什么 MCP 选了 JSON-RPC 2.0 呢？其实原因很朴素：MCP 需要一种「Client 调用 Server 的方法，Server 返回结果」的通信模式，这本质上就是远程过程调用（RPC）。而 JSON-RPC 2.0 是现成的、足够轻量的 RPC 规范，用 JSON 格式易读易调试，任何编程语言都能实现，不管 Server 是 Python 写的还是 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-RPC 本身只定义消息格式，不关心底层怎么传输，MCP 在此基础上定义了两种传输层实现。

传输方式一：stdio（标准输入输出）

stdio 是 MCP 最常用的传输方式，适合本地工具的场景。

工作原理：MCP Client（比如 Claude Desktop）在启动时，把 MCP Server 当作一个子进程启动，然后通过进程的标准输入（stdin）发送请求、从标准输出（stdout）读取响应。两个进程在同一台机器上运行，通过操作系统的管道通信。

stdio 方式有几个很明显的优点。首先延迟极低，进程间通信比走网络快得多，数据直接在操作系统管道里流转，几乎没有开销。其次不需要开端口，也就没有网络安全问题，不用担心外部访问。另外 Server 的生命周期是自动管理的，随 Client 启动而启动、随 Client 关闭而关闭，不需要你手动去管进程。

在实际使用中，你只需要在配置文件里告诉 Client「用什么命令启动 Server」就行了，比如在 Claude Desktop 的 claude_desktop_config.json 里这样配置：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",               // 启动命令
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"],
      "env": {}                       // 环境变量（可选）
    }
  }
}

传输方式二：SSE（Server-Sent Events）

SSE 适合远程部署的场景，Server 作为独立的 HTTP 服务运行，Client 通过网络连接访问。

SSE 是 HTTP 协议的一个特性：Client 发起一个普通的 HTTP GET 请求，Server 保持连接不断开，持续向 Client 推送数据流（每条消息以 data: 开头，以两个换行结束）。MCP 用 SSE 来实现 Server 向 Client 的消息推送，Client 向 Server 发请求则用普通的 HTTP POST。

SSE 方式的优点也很明确。Server 可以部署在云端，多个 Client 共享同一个 Server，这对团队来说特别实用，比如团队共用一个部署在服务器上的数据库 MCP Server，所有人连同一个服务就行，不需要各自在本地跑一份。而且支持跨机器访问，不局限于本地环境，适合需要统一管理工具服务的团队或平台。

当然，SSE 也有它的代价。相比 stdio 多了网络开销，延迟会略高一些，而且你还需要处理认证、网络中断重连等在本地场景下完全不用操心的问题。

新增的 Streamable HTTP 传输方式

你可能会想，SSE 已经能解决远程场景了，为什么还要搞一个新的？原因是 SSE 方式有一个架构上的小尴尬：Client 向 Server 发请求要走 POST，Server 向 Client 推数据要走 SSE 长连接，同一个对话用了两条通道，状态管理相对复杂。

MCP 规范在 2025 年更新后，新增了 Streamable HTTP 作为第三种传输方式，目标就是替代 SSE。它的核心改进是用单个 HTTP 端点同时处理请求和响应，不再需要维护两条通道。而且它还能降级为普通的 HTTP 请求/响应模式，也就是说，如果某个工具调用不需要流式输出，直接一个 POST 请求拿到结果就行，不用强制建立长连接。这让整体架构更加灵活，对不同场景的适配性也更好。目前 Streamable HTTP 还在逐步被各客户端采用中，但它是 MCP 传输层的未来方向。

🎯 面试总结

回到开头踩的雷，最常见的误区就是想当然地以为 MCP 用 WebSocket 或者 HTTP REST 接口。面试回答这道题，首先要说清楚 MCP 支持两种传输方式：本地场景用 stdio（标准输入输出，Server 作为子进程运行，通过管道通信），远程场景用 SSE（Server 作为 HTTP 服务部署，Client 通过长连接接收推送）。stdio 不走网络、延迟极低、生命周期自动管理；SSE 支持多 Client 共享一个 Server，适合团队统一部署。

第二个要点是消息格式和传输方式的解耦。不管用 stdio 还是 SSE，底层消息格式都统一用 JSON-RPC 2.0，切换传输方式不影响上层调用逻辑。这个解耦设计是面试官比较看重的点，说明你理解了 MCP 的分层架构，而不是把「消息格式」和「传输方式」混为一谈。

最后可以加分提一句 Streamable HTTP，这是 2025 年规范新增的第三种传输方式，作为 SSE 的升级替代，说明你对 MCP 的最新进展有关注。

---

对了，AI 工具调用的面试题会在「公众号@小林面试笔记题」持续更新，林友们赶紧关注起来，别错过最新干货哦！