MCP 官方规范：stdio 为本地服务端默认通信载体（权威原文依据）

一、规范原文结论

MCP 官方标准文档明确两点核心规则Model Cont...：

1. 协议内置两套标准传输层：stdio（标准输入输出）、Streamable HTTP（SSE 流式 HTTP）；
2. 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 是默认载体（设计定位）

1. 轻量化零配置 无需开放端口、防火墙、域名、鉴权，开箱即用，适配本地文件、本地数据库、本地脚本工具场景；
2. 安全隔离 进程隔离通信，仅本机可访问，不会暴露本地资源到局域网 / 公网；
3. 跨平台兼容 Windows/macOS/Linux 全平台原生支持 stdin/stdout，命令行程序天然适配；
4. 官方工具链首选 Claude Desktop、MCP Inspector、官方示例全部默认 stdio；HTTP-SSE 仅用于远程跨机器部署场景。

四、两种传输载体对比

表格

五、代码佐证（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 规范限制）

1. 调试时 print() 会输出到 stdout，破坏 JSON 报文，导致客户端解析报错；日志统一用 stderr；
2. 不能在程序启动时打印 banner、版本提示、欢迎文字；
3. stdio 服务同一时间只能被一个客户端连接（独占子进程），多客户端远程场景必须切换 HTTP-SSE。