浏览 MCP与Skills教程与资源
MCP stdio 与 Streamable HTTP 怎么选：进程、会话和错误证据
传输方式决定谁启动 Server、消息经过哪里、断线意味着什么。stdio 不等于离线，HTTP 也不一定是云服务；选错机制时，修改模型或反复换密钥都无济于事。
一边是子进程管道，一边是独立 HTTP 服务
当前规范修订为 2026-07-28，移除了旧式初始化握手与 HTTP 协议级会话；不少客户端和 Server 仍兼容 2025-11-25 及更早版本。下面先讲不依赖版本的进程差异，再给出两个协议时代的辨别方法。实际服务支持哪个版本，需要由客户端日志或响应确认，不能只看文档发布日期。
客户端负责启动进程
宿主按 command、args 和环境启动 Server，Client 从管道发送协议消息，Server 从 stdin 读取并向 stdout 返回。没有对外监听的 HTTP 端口，因此拿浏览器打开它没有意义。
stdout 是协议通道。启动横幅、调试 console.log 或 Shell 包装器额外打印文字，会让客户端在解析 JSON-RPC 之前就失败；诊断日志应写 stderr。Server 也可能在内部调用远程 API，所以 stdio 不能证明数据未离开本机。
服务先运行，客户端再连接
客户端访问一个 MCP 端点，服务进程可由个人电脑、公司服务器或 SaaS 运行。它需要 HTTP 处理及适当认证；连接 URL 可以是 127.0.0.1，也可以是公网 HTTPS。
响应可以是 JSON，也可以用 SSE 流式传输。2026-07-28 已移除独立 GET 事件流端点；旧版也允许不提供该可选流而返回 405，因此浏览器 GET 405 不能单独判失败。网页能打开只证明某条 HTTP 路径响应，不证明工具可用。
先看 Server 支持什么，再决定由谁承担运行责任
| 条件 | 选择与代价 | 改变结论的情况 |
|---|---|---|
| 个人电脑上的项目文件，Server 支持 stdio | stdio 通常省去监听端口和服务部署；运行时与升级由每台电脑承担。 | 团队已维护带身份验证的集中服务时，可以用 HTTP，但它未必能看到你的本机路径。 |
| 多个同事访问同一业务系统 | HTTP 便于集中维护；必须分清每个用户身份、资源权限和服务可用性。 | 如果远程服务只是共用一个高权限服务账号，集中部署并没有完成按用户授权。 |
| 本地独立应用已经提供 HTTP MCP | 直接连环回地址，保留它自己的生命周期。 | 从云端 Agent 看，127.0.0.1 指云端自身；本机可用不代表云端可访问。 |
| 提供方只有 stdio 启动方式 | 使用其受支持启动方式。 | 不能把 command 文本粘到 url；转换需要适配器，而适配器会新增认证、会话和运维责任。 |
2026 版每次请求带元数据，旧版先 initialize
下面是按 2026-07-28 规范构造的 tools/list 请求。保存为 mcp-list.json 后可对公开文档端点做版本探测；本页未实测该端点当前支持的协议版本，不预设它一定接受新规范。若返回 UnsupportedProtocolVersionError，应看其支持版本；如果是 HeaderMismatch，应修正请求，不能因同为 400 就一律回退旧版。
2026-07-28：单次工具发现请求
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list",
"params": {
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {"name": "transport-learning", "version": "1.0.0"},
"io.modelcontextprotocol/clientCapabilities": {}
}
}
}请求头与正文元数据必须一致
curl.exe -i -X POST "https://developers.openai.com/mcp" -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -H "MCP-Protocol-Version: 2026-07-28" -H "Mcp-Method: tools/list" --data-binary "@mcp-list.json"
2025-11-25 初始化消息示意
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-11-25",
"capabilities": {},
"clientInfo": {"name": "transport-learning", "version": "1.0.0"}
}
}macOS/Linux 将 curl.exe 改成 curl 即可。新规范的 tools/list 预期返回工具列表或明确协议错误；旧版还需 initialized 通知及可能的会话标识，所以这份旧消息不是完整客户端。实际使用优先交给对应客户端处理兼容，而非把几段 curl 拼成生产连接器。
错误必须放回它发生的那一层
stdio：ENOENT / command not found
- 原因
- 进程尚未启动；常见是可执行路径不存在，或 GUI 应用的 PATH 与终端不同。
- 怎么改
- 核对 command 指向真实程序，args 按数组分开。Windows 的 .cmd 启动包装和 macOS GUI 环境要按客户端教程处理，先不要调整 HTTP 认证。
stdio：Unexpected token，错误中夹着欢迎文字
- 原因
- 可能有非协议文本进入 stdout；也可能是启动脚本失败后把诊断写到了标准输出。
- 怎么改
- 从 Server stderr 和启动包装器定位输出来源，把非协议日志移到 stderr。stderr 有内容本身并不表示失败。
HTTP：浏览器 GET 返回 405
- 原因
- 该方法不被支持；在当前版规范中已不使用独立 GET 流，旧版也可能不提供该可选流。
- 怎么改
- 按已确认的协议版本构造 POST，检查 Content-Type、Accept 和元数据；不要仅因 GET 405 就改成 /sse。
旧版 HTTP：初始化后，下一次请求突然是会话错误
- 原因
- 2025 系列服务可能要求回传初始化给出的会话标识，或会话已失效；手写 curl 漏了状态也会发生。
- 怎么改
- 先确认确实在旧版兼容模式，再核对会话信息和时间。2026-07-28 已没有这套协议级会话，不给新规范硬加 Mcp-Session-Id。
HTTP：连接断开，但不知道工具是否已提交操作
- 原因
- 新规范将关闭 SSE 响应流视为取消信号，旧版规则不同；两者都不能保证已提交的业务写入回滚。
- 怎么改
- 先确认协议版本与服务日志，再按业务对象或请求标识回查。只有确认未提交或可安全去重时才重试；更换传输不会自动获得幂等性。
看到 SSE，要先问它指哪一代传输
2024-11-05 的 HTTP+SSE、2025 系列的 Streamable HTTP、2026-07-28 的 Streamable HTTP 必须分开。2026 版仍可把某次 POST 的响应做成 SSE，但已移除 GET 独立流与协议级会话，也改变了关闭响应流的取消语义。因此‘有 SSE’不足以判断年代，‘Streamable HTTP’这个名字也不保证会话规则相同。
旧示例写 /sse，新文档写 /mcp 时，不要机械替换后缀。这个后缀不是协议强制命名；服务实际部署的路径和支持的传输才决定能否连接。对于本机 HTTP，还要确认服务监听在环回地址，以及客户端真正运行在哪台机器。
资料与核对范围
资料核对日：2026-10-10。以下来源支持协议与配置说明；文中的命令、练习和预期结果不代表本站已在所有客户端和系统完成实测。
当前规范的请求元数据、无协议会话、取消与旧版兼容边界。
一手来源MCP 2026-07-28 Versioning逐请求版本机制与旧式握手时代的区别。
一手来源MCP 2025-11-25 Transports用于解释仍常见的旧版会话与 GET 事件流，不作为当前通用规则。
一手来源MCP 生命周期初始化、版本协商和 initialized 通知；手工 POST 不等于完整客户端。
一手来源OpenAI Docs MCP公开文档端点、只读能力和客户端连接示例。
一手来源Cursor MCP客户端实际支持的 stdio、SSE 与 Streamable HTTP 范围。