MCP 官方规范：stdio 为本地服务端默认通信载体（权威原文依据）
一、规范原文结论
MCP 官方标准文档明确两点核心规则Model Cont...：
- 协议内置两套标准传输层：stdio（标准输入输出）、Streamable HTTP（SSE 流式 HTTP）；
- stdio 是本地 MCP Server 的默认传输载体 ，官方强制要求：
Clients SHOULD support stdio whenever possible（客户端应尽可能兼容 stdio）；所有官方 SDK（TS/Python）启动服务时不指定 transport 则自动使用 stdio。
二、stdio 传输完整规范约束（必须遵守）
1. 进程模型
客户端（Claude Desktop、AI IDE）将 MCP Server 作为本地子进程拉起，依靠操作系统管道实现进程间双向通信，无网络端口、无 TCP 开销Model Cont...。
2. 数据流分工（硬性强制）
stdin(0)：客户端 → 服务端，只传换行分隔的 JSON-RPC 2.0 消息；stdout(1)：服务端 → 客户端，只能输出合法 MCP 报文，禁止打印日志、print 调试信息；stderr(2)：独立日志通道，打印日志、报错、调试输出，不干扰协议报文。
3. 消息帧规则
每条 JSON 消息以换行 \n 分割，JSON 内部不能自带换行；部分 SDK 会追加 Content-Length 头解决粘包问题。
三、为什么 stdio 是默认载体（设计定位）
- 轻量化零配置 无需开放端口、防火墙、域名、鉴权，开箱即用，适配本地文件、本地数据库、本地脚本工具场景；
- 安全隔离 进程隔离通信，仅本机可访问，不会暴露本地资源到局域网 / 公网；
- 跨平台兼容 Windows/macOS/Linux 全平台原生支持 stdin/stdout，命令行程序天然适配；
- 官方工具链首选 Claude Desktop、MCP Inspector、官方示例全部默认 stdio；HTTP-SSE 仅用于远程跨机器部署场景。
四、两种传输载体对比
表格
| 传输方式 | 默认与否 | 适用场景 | 通信方式 |
|---|---|---|---|
| stdio | ✅ 本地服务默认 | 本机本地工具、CLI、桌面 AI 客户端 | 子进程管道，单客户端独占 |
| Streamable HTTP(SSE) | ❌ 远程专用 | 服务器部署、多客户端、跨网络访问 | HTTP 长连接，支持多客户端并发 |
五、代码佐证（SDK 默认行为）
TypeScript
typescript
运行
// 不指定transport，默认StdioServerTransport
const server = new Server({ name: "demo", version: "1.0" });
server.connect(new StdioServerTransport());Python
python
运行
# 内置run()默认走stdio传输
server = Server("demo-server")
server.run()六、开发常见踩坑点（源于 stdio 规范限制）
- 调试时
print()会输出到 stdout，破坏 JSON 报文，导致客户端解析报错；日志统一用stderr； - 不能在程序启动时打印 banner、版本提示、欢迎文字；
- stdio 服务同一时间只能被一个客户端连接（独占子进程），多客户端远程场景必须切换 HTTP-SSE。