北京
2026年7月28日，无状态MCP规范正式发布。这意味着连接和配置一个MCP服务器目前有两种方式：一种是新规范下的无状态方式，另一种则是此前基于握手和会话ID的旧方式。对实际项目而言，这次变化意味着需要重新理解请求的建立、认证与状态维护。
在新规范中，最核心的改动有两项：一是移除初始化握手，二是移除会话ID。
在2025-11-25及更早的MCP版本中，客户端与服务器之间必须做一次完整的初始化握手。具体过程是：
1. 客户端发送 initialize 请求，其中包含协议版本、客户端能力和客户端信息；
2. 服务器返回 InitializeResult，包含协商后的版本、服务器能力和服务器信息，并可能返回 MCP-Session-Id；
3. 客户端再发送 notifications/initialized 通知；
4. 一切就绪后，正常 MCP 请求才开始。
这套流程的价值，是在真正调用工具或资源之前，先确认双方支持哪些特性。但从2026-07-28版规范开始，这个握手被删除了。每个请求都会自行携带协议版本和客户端元数据，于是不再需要服务端维护连接状态，请求可以被独立处理。
会话ID被移除也是同样的逻辑。任何带会话ID的机制本质上都有状态，因为服务端或数据库需要拿这个ID作为查找键，去查询对应的存储数据。类比一下：你登录Gmail之后，手机、笔记本等设备不需要每天重复登录，是因为每个设备背后都有一个会话在维持。无状态MCP要做的，就是省掉这类会话存储与查询过程。
除此之外，新规范在请求头与请求体的设计上也做了明确区分。普通HTTP头，比如 Content-Type、Accept、Content-Length，不需要写入请求体；但那些用于表达MCP调用语义的头，则必须同时出现在 header 和 body 中。这些头包括 MCP-Protocol-Version、Mcp-Method、Mcp-Name、Mcp-Param-* 等。这样设计的好处是，请求既能通过头部快速被路由和识别，也能在body里携带完整的调用参数，真正做到无状态、可独立处理。
总的来说，无状态MCP让每个请求变得更“自包含”。对于未来的MCP生态而言，服务端不再需要为每个客户端保存会话记录，这既降低了资源占用，也让水平扩展变得更加直接。对于开发者，迁移时只需要注意：不再依赖init握手，不再保存或使用会话ID，且按新规则同时维护header与body中的MCP字段。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
