MCP SSE 已经弃用了吗？是的，以及取代它的是什么

是的。最初 2024-11-05 版 MCP 规范中的 HTTP+SSE 传输在 2025-03-26 版规范中被弃用，由 Streamable HTTP 取代。当前的 2026-07-28 版规范依据新的功能生命周期政策，正式把它列为 Deprecated（已弃用），在该政策定稿三个月后即可被移除。新服务器应该使用 Streamable HTTP；在过渡期内，现有的 SSE 服务器在大多数客户端上仍然可以正常工作。

有一点需要区分清楚：SSE 作为一种格式并不会消失。服务器需要时，Streamable HTTP 仍然会用 Server-Sent Events 来流式返回响应。被弃用的是旧的传输设计——也就是围绕一条长连接 SSE 和另一个独立 POST 端点构建的那套方案。

新旧对比一览

为什么要替换它

SSE 设计在生产环境中很难运维。每个客户端在连接期间都要保持一条打开的连接；对 POST 的回复却从另一条连接返回，所以负载均衡器必须把两者都转发到同一个实例。请求超时较短的 Serverless 平台无法可靠地托管它。Streamable HTTP 用一个端点和普通的请求/响应语义解决了这些问题。只有在最终结果返回前需要流式推送进度或通知时，服务器才会升级为 SSE。

2025-03-26 之后有哪些变化

Streamable HTTP 自身在推出后也经历了变化：

• 2025-03-26：推出 Streamable HTTP。它支持可选会话（Mcp-Session-Id）、用于服务器主动消息的可选独立 GET 流，以及通过 Last-Event-ID 实现的可恢复流。
• 2025-06-18 和 2025-11-25：新增 MCP-Protocol-Version 请求头，并收紧了授权规则。传输的整体形态保持不变。
• 2026-07-28（changelog）：MCP 变成无状态协议。initialize 握手和协议级会话被移除；GET 流被 subscriptions/listen 请求取代；可恢复性被移除；POST 必须携带 Mcp-Method 和 Mcp-Name 请求头，方便网关在不解析请求体的情况下路由。同一版本还把 HTTP+SSE 正式重新归类为 Deprecated（SEP-2596）。

实际上，2025 年中写的"Streamable HTTP"服务器和今天写的服务器，在线路上看起来略有不同。当前的 SDK 两种都能处理。

向后兼容：新旧两端如何通信

规范定义了一套回退机制，让不同时期的客户端和服务器依然可以互通：

• 同时支持两种传输的客户端会先向 URL 发送 POST。如果返回 400、404 或 405，就改发 GET；如果服务器返回 SSE endpoint 事件，就继续使用旧传输。
• 想继续服务旧客户端的服务器，会在新的 /mcp 端点旁边同时保留旧的 /sse 和 /messages 端点。
• 收到 2025 时期 Streamable HTTP 流量的 2026-07-28 服务器，会对 GET/DELETE 返回 405，并忽略 Mcp-Session-Id 和 Last-Event-ID。客户端如果收到 400 且其中没有可识别的新版错误，就回退到 initialize。

官方 SDK v2 把这些规则落实到了代码中：

• TypeScript（@modelcontextprotocol/server 2.x）：服务器端已完全不再提供 HTTP+SSE。createMcpHandler 提供 Streamable HTTP，并默认以无状态方式响应 2025 时期的客户端。对于暂时无法迁移的部署，@modelcontextprotocol/server-legacy/sse 中提供了一份冻结副本，它已被弃用，计划在 v3 中移除。客户端仍然包含 SSEClientTransport。
• Python（mcp 2.x）：mcp.run(transport="sse") 仍可为旧客户端工作，但文档明确表示不要在它之上构建任何新东西。客户端仍可通过 sse_client(...) 连接。

客户端还支持 SSE 服务器吗？

目前大多数仍然支持。截至 2026 年 10 月：

"已弃用"这个标签说明了未来的方向。新的客户端和网关可能只支持 Streamable HTTP。一旦规范移除这种传输，SDK 也会随之删除它。

这对你意味着什么

取决于你站在连接的哪一端：

• 你在使用 MCP 服务器。 目前什么都不会坏。如果某个服务器的文档同时提供 /sse 和 /mcp 两个 URL，请选择 /mcp，并把客户端的传输方式设为 HTTP。只对那些别无选择的服务器保留 /sse URL，并做好它们迁移或消失的准备。
• 你在维护 SSE 服务器。 趁客户端仍然同时支持两种传输，现在就规划迁移。新旧端点可以并行运行，你的用户不需要在某一天统一切换。
• 你在开发客户端或网关。 优先实现 Streamable HTTP。只在用户仍需连接旧服务器期间保留 SSE 回退，并记录它被使用的情况，这样你就知道什么时候可以移除它。

如何判断服务器用的是哪种传输

• 以 /sse 结尾的 URL 几乎都是旧传输；/mcp 通常意味着 Streamable HTTP。
• 快速探测：带上 Accept: application/json, text/event-stream 发送一个 MCP POST 请求。Streamable HTTP 服务器会返回 JSON 或 SSE message 事件；只支持旧传输的服务器通常会对 POST 返回 404/405，只在 GET 时才打开流。
• 或者让 MCP Inspector 用 --transport http 连接，看能否成功。

服务器作者的迁移步骤

1. 升级 SDK。 TypeScript：从 @modelcontextprotocol/sdk 1.x 迁移到 @modelcontextprotocol/server 2.x（升级指南附带 codemod）。Python：升级到 mcp 2.x，其中 FastMCP 已改名为 MCPServer。
2. 替换传输接线。 TypeScript：去掉 SSEServerTransport 以及 /sse 和 /messages 路由，在一个路由（例如 /mcp）上提供 createMcpHandler(factory)。Python：把 transport="sse" 改成 transport="streamable-http"。
3. 把状态移出连接。 原来按 SSE 会话保存的任何东西（已登录用户、游标、缓存）都应放进你自己的存储，以认证用户或作为工具参数传递的 ID 为键。
4. 暂时保留旧端点。 在 /mcp 旁边继续提供冻结版 SSE 传输，让现有配置继续可用，并记录还有多少流量访问 /sse。
5. 更新公开的 URL。 修改 README、注册表中的 server.json（remotes 中设置 "type": "streamable-http"）以及你的 MCP.so 收录信息，让它们指向 /mcp。
6. 测试两个时期的客户端。 用 Inspector 以 --transport http 测试新端点，以 --transport sse 测试旧端点。等流量归零后，或在规范移除它之前，删除 /sse。
7. 重新检查代理配置。 Streamable HTTP 仍会流式返回部分响应，所以要在 nginx 等代理上关闭 text/event-stream 的响应缓冲，并设置合理的超时时间。

迁移后的服务器如何托管，请看如何部署 MCP 服务器。想复习协议本身，请看 MCP 是如何工作的。

下一步

在 MCP 服务器目录中浏览已经提供 Streamable HTTP 端点的服务器。Sentry、Notion 和 GitHub 等官方远程服务器，都是参考当前做法的好例子。