F3.5 F3

本地用 stdio，远程用 HTTP：选择 MCP 传输方式

MCP 支持多种传输方式，因为 MCP server 部署在不同的地方。跑在你笔记本上的代码分析工具和跑在团队基础设施里的共享数据库服务器，通信需求完全不同。传输方式应该匹配 server 运行的位置。

三种传输选项

  1. stdio — 标准输入/输出。Client 把 MCP server 作为子进程启动，通过进程的 stdin 和 stdout 流通信。没有网络、没有端口、没有端点。就是管道。

  2. HTTP + SSE — HTTP 处理 client 到 server 的请求，Server-Sent Events 处理 server 到 client 的推送通知。这是网络可达 server 的 web 友好选项。

  3. Streamable HTTP — 一种现代的双向 HTTP 流传输，支持请求-响应和 server 发起的通信。三者中最新的一种。

三种方式都用 JSON-RPC 2.0 做消息编码。不是 Protocol Buffers，不是自定义二进制格式——全线 JSON-RPC。

stdio：本地 server 的默认选择

Claude Code 对本地 MCP server 主要使用 stdio。流程很简单：Claude Code 启动 server 进程，通过 stdin 发 JSON-RPC 消息，从 stdout 读响应。不需要网络配置，不会有端口冲突，没有防火墙问题。

所以 stdio 是所有跟 client 运行在同一台机器上的 MCP server 的天然选择。它是最简单的搭法——一条命令启动进程，通信就通了。跨平台，零依赖。

HTTP 类传输：给远程 server 用

当 MCP server 在另一台机器上——团队的共享数据库服务器、云托管服务、CI/CD 基础设施工具——你需要网络通信。这就是 HTTP + SSE 和 Streamable HTTP 的用武之地。

这些传输方式要求 server 暴露一个端点，client 知道它的 URL。比 stdio 多些配置，但 server 不是本地进程时就必须这么做。

传输方式匹配部署环境

规则很直接：

  • 本地 server，同一台机器 → stdio。更简单，无网络开销，不用管端口。
  • 远程 server，不同机器 → HTTP 类传输。网络访问必须的。

别想复杂了。本地 server 用 HTTP 会多出不必要的复杂度（端点配置、端口管理）。远程 server 用 SSH 隧道跑 stdio 会多出不必要的脆弱性。每种传输方式存在都有原因——用在它该用的地方。

没有中心化注册表

MCP server 在 client 的配置文件里直接配置。你指定命令（stdio server）或 URL（HTTP server）。没有 MCP 中心注册表要求 server 先注册了 client 才能连接。发现是显式的，不是自动的。

所有传输方式，同样的能力

一个常见误解：某些传输方式会限制可用的 MCP 原语（Tools、Resources、Prompts）。不会。三种传输方式都支持完整的 MCP 协议。传输方式影响的是 client 和 server 怎么通信，不是能做什么。

一句话总结： 本地 MCP server 用 stdio（Claude Code 的默认选择），远程的用 HTTP 类传输——所有传输方式都通过 JSON-RPC 2.0 支持完整协议，不需要注册表。