SEP-2575: 使 MCP 无状态

Documentation Index

Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt

Use this file to discover all available pages before exploring further.

​

摘要

​

动机

​

有状态性的問題

1. 阻碍可扩展性： 最关键的问题是有状态 MCP 难以进行负载均衡。简单的无状态负载均衡器（例如 L4/L7 轮询）无法使用，因为它会将客户端请求路由到不同的后端服务器，而这些服务器都不会拥有正确的会话状态。运维人员不得不实现诸如粘性会话之类复杂且脆弱的方案，将客户端绑定到特定服务器。这会使基础设施复杂化，可能导致负载分配不均，并使服务的水平扩展变得不平凡。
2. 弹性和故障容忍性较差： 在有状态模型中，如果处理某个客户端会话的特定服务器实例失败，该会话状态就会丢失。客户端必须检测连接失败、重新建立连接（很可能通过负载均衡器连接到新的服务器实例），并再次执行整个初始化握手。这个过程具有破坏性且效率低下，并增加了围绕“可恢复性”的复杂性。
3. 实现复杂度增加： 当前模型给开发者带来了显著负担。
   • 服务端： 开发者必须实现逻辑来创建、管理并最终回收每个客户端的会话状态。这是 bug 和内存泄漏的常见来源。
   • 客户端： 开发者必须编写复杂代码来管理持久连接，并处理不可避免的网络故障和重连，包括断连后重新同步状态的逻辑。

​

设计原则

1. 优先无状态： 只要可能，请求必须是自包含的，提供服务器处理它所需的全部信息，而不依赖先前请求中的状态。
2. 优先状态引用： 如果完全无状态的交换不现实，应在每个请求中传递对状态的引用。
3. 将有状态性视为最后手段： 只有在不存在更简单的替代方案来解决关键用例时，才应接受有状态逻辑和长生命周期流连接的复杂性。

​

传输一致性

​

规范

​

概览

1. MCP 协议版本
2. 服务器能力和 serverInfo
3. 客户端能力和 clientInfo

注意： 会话管理（包括传输层和应用层）由 SEP-2322 和 SEP-2567 单独处理。此 SEP 仅专注于移除初始化握手，并为版本协商、发现和能力提供无状态替代方案。

​

协议版本

​

HTTP

• MCP-Protocol-Version: 2025-06-18
  • 用途：通知服务器客户端在此特定请求中使用的是 MCP 规范的哪个版本。
  • 要求：此头部是强制性的。服务器应拒绝缺少版本或版本不受支持的请求。
  • 此头部 MUST 与下文请求中指定的值匹配。

​

每请求版本

export interface RequestMetaObject extends MetaObject {
  progressToken?: ProgressToken;
+ /**
+  * 本次请求所使用的 MCP 协议版本。
+  */
+ "io.modelcontextprotocol/protocolVersion": string;
  // 以下将在“每请求客户端能力”部分引入额外的每请求字段（clientInfo、clientCapabilities、logLevel）。
}

​

不受支持的协议版本

export const UNSUPPORTED_PROTOCOL_VERSION = -32004;

export interface UnsupportedProtocolVersionError extends Omit<
  JSONRPCErrorResponse,
  "error"
> {
  error: Error & {
    code: typeof UNSUPPORTED_PROTOCOL_VERSION;
    data: {
      /**
       * 服务器支持的协议版本字符串数组。
       */
      supported: string[];
      /**
       * 客户端请求的协议版本。
       */
      requested: string;
    };
  };
}

​

版本协商流程

1. 客户端发送请求时，在 MCP-Protocol-Version 头和 io.modelcontextprotocol/protocolVersion _meta 字段中带上其首选协议版本。
2. 如果服务器支持该版本，它会正常处理该请求。
3. 如果服务器不支持所请求的版本，它会返回一个 UnsupportedProtocolVersionError，其中包含其 supported 版本列表。
4. 客户端从列表中选择一个双方都支持的版本并重试。

​

服务器能力发现

​

server/discover RPC

• 用途：允许客户端查询服务器支持的协议版本、能力以及其他元数据。

export interface DiscoverRequest extends Request {
  method: "server/discover";
  params?: {};
}

export interface DiscoverResult extends Result {
  /**
   * 此服务器支持的 MCP 协议版本字符串列表。
   * 客户端应从该列表中选择一个版本用于后续请求。
   */
  supportedVersions: string[];

  /**
   * 描述服务器能力的对象。
   */
  capabilities: ServerCapabilities;

  /**
   * 有关服务器软件实现的信息。
   */
  serverInfo: Implementation;

  /**
   * 描述如何使用服务器及其功能的自然语言说明。
   * 客户端可借此提升 LLM 对可用工具的理解（例如，将其包含在系统提示中）。
   */
  instructions?: string;
}

​

每请求客户端能力

​

每请求元数据 Schema

export interface RequestMetaObject extends MetaObject {
  progressToken?: ProgressToken;
  /**
   * 本次请求所使用的 MCP 协议版本。
   */
  "io.modelcontextprotocol/protocolVersion": string;
  /**
   * 标识客户端软件。
   */
  "io.modelcontextprotocol/clientInfo": Implementation;
  /**
   * 本次请求中客户端的能力。
   */
  "io.modelcontextprotocol/clientCapabilities": ClientCapabilities;
  /**
   * 本次请求期望的日志级别。
   */
  "io.modelcontextprotocol/logLevel"?: LoggingLevel;
}

• "io.modelcontextprotocol/protocolVersion"：string — MCP 协议版本。必需。 协商细节见上文“协议版本”部分。
• "io.modelcontextprotocol/clientInfo"：Implementation — 标识客户端软件。必需。 Implementation Schema 要求 name 和 version；其他字段为可选。
• "io.modelcontextprotocol/clientCapabilities"：ClientCapabilities — 本次请求中客户端的能力。必需。
• "io.modelcontextprotocol/logLevel"：LoggingLevel — 本次请求期望的日志级别。可选。 如果缺失，服务器 MUST NOT 为此请求发送任何日志通知。客户端通过显式设置级别来选择接收日志消息。取代 logging/setLevel RPC。

​

响应流

​

请求取消

• HTTP。 关闭 SSE 响应流 MUST 被服务器视为取消该请求。由于每个请求都有自己的响应流，传输层断开是明确无歧义的。
• STDIO。 客户端 MUST 发送一个引用请求 ID 的 notifications/cancelled 通知。STDIO 只有一个共享通道，因此没有可关闭的每请求流。

移除可恢复流

​

缺少必需能力

export const MISSING_REQUIRED_CLIENT_CAPABILITY = -32003;

export interface MissingRequiredClientCapabilityError extends Omit<
  JSONRPCErrorResponse,
  "error"
> {
  error: Error & {
    code: typeof MISSING_REQUIRED_CLIENT_CAPABILITY;
    data: {
      /**
       * 服务器处理此请求所需的客户端能力。
       */
      requiredCapabilities: ClientCapabilities;
    };
  };
}

​

subscriptions/listen RPC

​

请求 Schema

export interface SubscriptionsListenRequest extends Request {
  method: "subscriptions/listen";
  params: {
    _meta: {
      "io.modelcontextprotocol/protocolVersion": string;
      "io.modelcontextprotocol/clientInfo": Implementation;
      "io.modelcontextprotocol/clientCapabilities": ClientCapabilities;
      // ... 其他 meta 字段
    };

    /**
     * 客户端希望在此流上接收的通知。
     * 每种通知类型都需要显式选择加入；服务器 **MUST NOT** 发送
     * 客户端未在此处明确请求的通知类型。
     */
    notifications: {
      /**
       * 若为 true，接收 notifications/tools/list_changed。
       */
      toolsListChanged?: boolean;

      /**
       * 若为 true，接收 notifications/prompts/list_changed。
       */
      promptsListChanged?: boolean;

      /**
       * 若为 true，接收 notifications/resources/list_changed。
       */
      resourcesListChanged?: boolean;

      /**
       * 订阅特定资源 URI 的 notifications/resources/updated。
       * 取代 resources/subscribe RPC。
       */
      resourceSubscriptions?: string[];
    };
  };
}

​

确认通知

• 客户端显式取消它（HTTP 上关闭 SSE 流，或在 STDIO 上发送 notifications/cancelled）；
• 底层连接关闭（HTTP 超时、TCP 断开、STDIO 进程退出）；或
• 服务器将其拆除（例如关机），在这种情况下它 MUST 关闭 SSE 流（HTTP）或发送引用该订阅请求 ID 的 notifications/cancelled（STDIO）。

export interface SubscriptionsAcknowledgedNotification extends Notification {
  method: "notifications/subscriptions/acknowledged";
  params: {
    /**
     * 服务器同意接受的通知订阅。
     * 仅包含服务器实际支持的通知类型。
     * 如果客户端请求了不支持的通知类型
     * （例如，当服务器没有 prompts 时请求 promptsListChanged），
     * 则会从此集合中省略。
     */
    notifications: {
      toolsListChanged?: boolean;
      promptsListChanged?: boolean;
      resourcesListChanged?: boolean;
      resourceSubscriptions?: string[];
    };
  };
}

​

多个并发订阅

{
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/subscriptionId": "<original listen request id>"
    }
  }
}

​

停止订阅

• HTTP。 关闭 SSE 响应流即可停止订阅。
• STDIO。 客户端发送引用 listen 请求 ID 的 notifications/cancelled。服务器 MUST 停止向该订阅发送通知。

​

传输行为

​

已弃用和已移除的 RPC

• initialize / notifications/initialized：初始化握手已移除。版本协商现在通过每请求的 MCP-Protocol-Version 头和 _meta 字段处理。能力发现由 server/discover 处理。
• logging/setLevel：已移除。日志级别现在通过 'io.modelcontextprotocol/logLevel' _meta 字段按请求指定。没有替代 RPC。
• roots/list：作为顶层服务器到客户端 RPC 已移除。需要客户端 roots 的服务器 MUST 通过 MRTR ListRootsRequest 机制请求它们（见 SEP-2322）。
• notifications/roots/list_changed：已移除。Roots 通过 MRTR 按需获取，因此不需要变更通知。
• resources/subscribe / resources/unsubscribe：这些方法已移除。资源订阅本质上是有状态的——服务器必须记住每个客户端订阅了哪些资源。取而代之，客户端在 subscriptions/listen 请求的 notifications 参数中声明其希望接收更新的资源。服务器在 listen 流上为匹配的资源发送 notifications/resources/updated。
• ping：在双向上都已移除。服务器到客户端的 ping 被移除，因为服务器不能再独立发送请求。客户端到服务器的 ping 也被移除，因为任何正常的 RPC 调用已经证明服务器存活，而传输层机制（HTTP keep-alive、SSE 注释、STDIO 进程状态）能更合适地处理连接健康检查。

​

原理

​

默认采用无状态优先

​

考虑过的替代方案：可选握手

​

为什么被否决：

​

显式会话管理

​

职责分离

• 发现：由 server/discover 专门处理。
• 能力：通过 _meta 字段按请求处理，或通过 subscriptions/listen RPC 处理。

​

考虑过的替代方案：单一、整体式握手

​

为什么被否决：

​

向后兼容性

​

支持多个版本

​

客户端（支持 vPrev）→ 服务器（vPrev, vPost）

1. 客户端发送初始化
2. 服务器支持 vPrev，因此会按规范返回初始化结果
3. 客户端和服务器按 vPrev 进行通信。

​

客户端（支持 vPrev, vPost）→ 服务器（vPrev）

1. 客户端发送带有 MCP 协议版本 _meta 字段的 server/discover，并将其设置为首选的 vPost。
2. 如果服务器支持 vPost（或客户端也支持的任何 vPost 风格版本），客户端将使用发现到的版本进行后续请求。
3. 如果服务器返回“不支持的协议版本”或“未找到方法”，客户端将回退到其支持的旧版本，并执行 initialize 握手。

​

安全影响

​

参考实现

​

常见问题

​

什么是协议级无状态？

无状态协议是一种通信协议，在这种协议中，接收方不得保留先前请求中的会话状态。发送方以一种方式将相关会话状态传递给接收方，使得每个请求都可以独立理解，也就是说，无需参考接收方保留的先前请求中的会话状态。

​

这会让 MCP 成为完全无状态的协议吗？

​

为什么让 STDIO 也保持无状态很重要？

​

server/discover 与 MCP Server Card 有什么关系？

​

开放问题

​

_meta 中应放什么，什么应作为顶层协议字段？

​

clientInfo 应该成为 ClientCapabilities 的一部分吗？