MCP Transport：stdio 与 Streamable HTTP

为什么重要

Transport 决定进程管理、鉴权方式、会话边界和故障模式；选型错误会把本地工具拖进网络复杂度，或让远程服务无法多客户端共享。

核心原理

Transport（传输层）只负责搬运 JSON-RPC 消息，方法、参数和结果在两种方式下完全一致。stdio 模式下 Host 把 Server 作为子进程拉起，消息写进子进程的标准输入输出，进程即会话，权限继承操作系统用户，不需要网络鉴权——Claude Desktop 接本地工具就是这个形态。Streamable HTTP 把 Server 当远程服务：Client 用 HTTP POST 发消息，服务端可用 SSE（Server-Sent Events，服务器向客户端的单向推送流）回推消息，并用会话头维护多客户端状态；鉴权（通常 OAuth 或 Bearer Token）、TLS 和水平扩展都要自己解决。选型规则很直接：要用本地文件、本地命令、跟随用户机器权限，选 stdio；要做团队共享的远程服务、统一鉴权和多客户端接入，选 Streamable HTTP。本站 POST /api/mcp 就是后者的一个无状态子集：单 POST 单响应、不开 SSE、不维持会话，专门用来演示数据层。

工程实现

• 本地集成用 stdio，远程共享服务用 Streamable HTTP
• stdio 要管进程生命周期：启动参数、stderr 日志、退出重启
• 远程形态先解决鉴权与 TLS，再暴露工具
• 无状态单请求子集最易起步，SSE 推送可后补

展开说明

常见误区

• 给远程共享服务套 stdio，每台客户端机器都得装一遍 Server
• stdio Server 把日志写进 stdout，污染 JSON-RPC 消息流（日志必须走 stderr）
• 远程 Server 不做鉴权就把工具暴露到公网

面试怎么说

数据层不变，传输层二选一：stdio 是本地子进程、进程即会话、免网络鉴权，适合桌面宿主与本地工具；Streamable HTTP 是远程服务，要自己处理鉴权、TLS 与多客户端会话，适合共享部署。按部署形态选，不按功能选。