传输层
MCP支持两种官方传输方式，同时允许自定义传输实现。
3.1 stdio传输
原理: 通过标准输入(stdin)和标准输出(stdout)流通信。Host启动Server子进程，通过管道交换JSON-RPC消息。每条消息以换行符分隔。
适用场景: Server和Client在同一台机器上运行。
优势:
- 零网络开销，延迟最低
- 无需配置端口、证书
- 安全（不暴露网络接口）
- 实现简单
劣势:
- 只能本地使用
- 一个Server进程只服务一个Client
配置示例 (Claude Desktop):
{
"mcpServers": {
"my-local-server": {
"command": "node",
"args": ["/path/to/my-server/index.js"],
"env": { "DB_URL": "postgresql://..." }
}
}
}
node /path/to/my-server/index.js 子进程，通过stdin/stdout通信。Server的stderr可以用于日志输出，不会干扰协议。
3.2 Streamable HTTP传输
状态: 当前推荐的远程传输方式（协议版本 2025-11-25）。
原理: Client和Server通过单一HTTP端点通信。Client用POST发送JSON-RPC请求，Server可以用Server-Sent Events (SSE)实现流式响应和主动推送。
适用场景: Server部署在远程（云服务器、SaaS服务等）。
核心机制
单一MCP端点: Server暴露一个端点（如 /mcp），处理两种HTTP方法：
- POST: Client发送JSON-RPC请求。Server可以返回单个JSON响应，或以SSE流返回多个消息。
- GET: Client建立SSE连接，用于接收Server的主动推送（通知、请求等）。
会话管理: 通过 Mcp-Session-Id HTTP头管理有状态会话：
// Server在initialize响应中返回Session ID
Mcp-Session-Id: session-abc123
// Client在后续所有请求中携带
Mcp-Session-Id: session-abc123
MCP-Protocol-Version 头：
MCP-Protocol-Version: 2025-11-25
Last-Event-ID 机制实现断线重连。Client在重连时发送上次收到的事件ID，Server从该点继续推送：
// SSE事件包含ID
id: evt-42
event: message
data: {"jsonrpc":"2.0","method":"notifications/tools/list_changed"}
// Client重连时携带
Last-Event-ID: evt-42
- 支持远程访问
- 一个Server可服务多个Client（通过Session ID区分）
- 支持标准HTTP认证（OAuth 2.1、API Key等）
- 支持负载均衡和水平扩展
- 支持断线重连和消息恢复
配置示例
{
"mcpServers": {
"my-remote-server": {
"url": "https://my-server.example.com/mcp",
"headers": {
"Authorization": "Bearer your-token-here"
}
}
}
}
3.3 已弃用：HTTP+SSE传输
协议版本 2024-11-05 中定义的 HTTP+SSE 传输方式已被弃用。该方式使用两个独立端点（一个SSE端点用于Server推送，一个POST端点用于Client请求），设计较复杂且不支持会话恢复。所有新实现应使用 Streamable HTTP。
| 特性 | HTTP+SSE (已弃用) | Streamable HTTP (当前) |
|---|
| 端点数量 | 2个（SSE + POST） | 1个（统一端点） |
| 会话管理 | 无标准化方案 | Mcp-Session-Id 头 |
| 断线恢复 | 不支持 | 支持（Last-Event-ID） |
| 协议版本 | 2024-11-05 | 2025-11-25 |
| 状态 | 已弃用 | 推荐使用 |
3.4 自定义传输
MCP允许实现自定义传输层，只要满足JSON-RPC 2.0消息交换的基本要求：双向消息传递、请求-响应匹配、通知推送。例如，可以基于WebSocket、gRPC或自定义TCP协议实现。
3.5 选型指南
| 场景 | 推荐传输 | 原因 |
|---|
| 开发测试 | stdio | 简单，无需部署 |
| 个人工具 | stdio | 只在自己电脑用 |
| 团队内部工具 | Streamable HTTP | 多人共用 |
| SaaS产品 | Streamable HTTP | 面向外部用户 |
| 商务MCP Server | Streamable HTTP | 需要AI代理远程调用 |
| 高安全要求 | stdio | 不暴露网络接口 |
| 需要水平扩展 | Streamable HTTP | 支持多实例和负载均衡 |
3.6 OAuth 2.1认证
远程MCP Server的认证基于 OAuth 2.1（draft-ietf-oauth-v2-1-13），这是MCP规范推荐的标准认证机制。详细内容见第7章：安全与认证。
认证流程概览：
1. Client向Server MCP端点发送请求
2. Server返回401，携带Protected Resource Metadata (RFC 9728)
3. Client获取Authorization Server Metadata (RFC 8414)
4. Client进行Dynamic Client Registration (RFC 7591，如需)
5. Client引导用户完成OAuth授权（PKCE必需，S256方法）
6. Client获得access_token (Bearer token)
7. 后续请求在Authorization头携带token
下一章: 构建MCP Server — TypeScript和Python的完整开发指南
