一句话定义：传输方式（transport）指 AI 客户端与 MCP（Model Context Protocol）服务器之间，消息通过什么通道送达。目前主流两种：stdio（standard input/output，标准输入输出）和 Streamable HTTP。
两者根本差异：谁负责建立连接
stdio 的连接建立在进程之间。客户端先把 MCP 服务器当作本机子进程启动，再通过该进程的标准输入和标准输出收发 JSON-RPC 消息。因此其配置参数必然是“如何启动这个程序”：可执行命令（command）、启动参数（args）、环境变量（env，常用来传 API Key）。这段配置相当于一份启动指令。
Streamable HTTP 的连接建立在网络上。服务器已运行在某个地址，客户端只需向该 URL 发 HTTP 请求，把 JSON-RPC 消息放在请求体里；服务器可直接返回一段 JSON，也可升级为 SSE（Server-Sent Events）流式推送，实现边计算边返回。因此其配置参数是 URL 和请求头（headers，常用来带认证 token）；多客户端场景下还会传递会话标识（session id）。这里本质上是一个网络端点加一套凭证。
打个比方：stdio 像把师傅请到家里干活。你得告诉他走哪个门、带什么工具，他在屋里干，你关门他就走。Streamable HTTP 像打电话给外面的服务台。你只需要号码和通行证，对面几台机器、几个人接、在哪个机房，你都不用管。
| 维度 | stdio | Streamable HTTP |
|---|---|---|
| 连接对象 | 本机子进程 | 网络端点 |
| 关键参数 | command、args、env | URL、headers |
| 谁能用 | 一般只有启动它的那个客户端 | 多个客户端可共享 |
| 生命周期 | 随客户端启动和退出 | 服务器独立长期运行 |
| 典型场景 | 本地文件、本地数据库、IDE 内工具 | 团队共享服务、SaaS 工具、云端数据源 |
容易混淆的相邻概念
一是传输层与协议层。换传输方式不改变“有哪些工具、参数怎么定义”；工具、资源、提示词模板这些能力声明在两种传输下完全一样，变的只是消息怎么送。二，Streamable HTTP 与其前身“HTTP + SSE”方案不同：早期要两个端点，一个长连接收、一个 POST 发；现在合并为单一端点，由服务器决定这次要不要流式返回。
实际意义
第一，八成的配置报错源于把两种传输方式搞混了：本地服务器填了 URL，自然连不上；远程服务器填 command，更无从启动。看配置里有没有 URL 是最快判断方法，具体字段名以 MCP 官方规范页面为准。
第二，安全边界不同。stdio 服务器继承启动它的用户权限、跑在本机，风险主要在“别乱给权限”；Streamable HTTP 服务器暴露在网络中，要考虑认证、鉴权、谁能访问哪些数据，以及防止被当成跳板。
第三，运维方式不同。stdio 是“一个客户端一个进程”，用完即弃；HTTP 服务器是可以被很多人共用的长期服务，也能按需做无状态横向扩展。选哪种，本质上是问：这个工具属于某个人，还是属于一个团队？