2.3 MCP 连接生命周期：Lifecycle

MCP 定义了一个严格的生命周期，用于客户端-服务器连接，确保了通信双方能进行适当的状态管理和能力协商。

MCP 连接生命周期主要分为三个阶段：

初始化阶段：客户端与服务器进行协议版本和能力协商。
操作阶段：客户端与服务器按照协议正常通信，交换消息。
关闭阶段：客户端与服务器各自优雅地终止连接。

MCP 连接生命周期内，客户端与服务器交互示例：

2.3.1 初始化阶段

建立连接

MCP 连接生命周期的初始化阶段，是客户端与服务器的第一次交互，双方建立连接，协商通信使用的协议版本，各自声明支持的特性。

客户端发送初始化请求的消息示例：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "roots": {
        "listChanged": true
      },
      "sampling": {}
    },
    "clientInfo": {
      "name": "ExampleClient",
      "version": "1.0.0"
    }
  }
}

服务器在接到客户端的初始化请求之后，必须响应其自身的能力和信息。响应消息示例如下：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "logging": {},
      "prompts": {
        "listChanged": true
      },
      "resources": {
        "subscribe": true,
        "listChanged": true
      },
      "tools": {
        "listChanged": true
      }
    },
    "serverInfo": {
      "name": "ExampleServer",
      "version": "1.0.0"
    },
    "instructions": "Optional instructions for the client"
  }
}

收到服务器响应之后，客户端必须发送一个已初始化通知，表明它已准备好开始正常操作。

客户端发送的已初始化通知消息示例：

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

由以上步骤可以得知，MCP 客户端与服务器在初始化阶段建立连接的过程跟 TCP 的三次握手过程类似。TCP 三次握手过程如图所示：

版本协商

在初始化请求中，客户端必须发送它支持的最新协议版本。

如果服务器支持请求的协议版本，它必须以相同版本响应。否则，服务器必须响应其支持的最新版本。
如果客户端不支持服务器响应的版本，它应该断开连接。

能力协商

客户端与服务器在初始化阶段，通过能力协商确定会话期间将用到哪些功能特性。

客户端与服务器支持的功能特性包括：

分类	功能特性	描述
客户端	`roots`	提供文件系统根列表
客户端	`sampling`	支持大模型采样
客户端	`experimental`	支持非标准实验特性
服务端	`prompts`	提供提示词模板
服务端	`resources`	提供可读资源
服务端	`tools`	支持工具调用
服务端	`logging`	支持结构化日志
服务端	`experimental`	支持非标准实验特性

功能特性的能力声明可以包含子选项，例如：

listChanged：支持列表变更通知（用于提示词、资源、工具、根等）
subscribe：支持订阅单个内容的变更通知（仅限资源）

2.3.2 操作阶段

MCP 客户端与服务器在初始化阶段建立连接之后，进入操作阶段，开始正常通信，交换消息。

在操作阶段，通信双方应该遵守以下原则：

尊重协商的协议版本
仅使用协商的功能特性

2.3.3 关闭阶段

MCP 客户端与服务器在关闭阶段断开连接。一方（通常是客户端）主动终止连接，另一方（通常是服务器）应使用底层传输机制来终止连接。

stdio

对于基于 stdio 传输通信的双方，应通过以下方式启动关闭流程：

首先，客户端关闭对子进程的输入流（服务器的 stdin）
等待服务器退出，或者当服务器未在合理时间内退出时发送 SIGTERM 信号
如果在给服务器发送 SIGTERM 后，服务器合理时间内仍未退出，则继续给服务器发送 SIGKILL 信号

服务器通过关闭对客户端的输出流（stdout）来完成关闭流程。

HTTP

对于基于 HTTP 传输通信的双方，关闭 HTTP 连接即可。

2.3.4 超时机制

MCP 实现方应为所有发送的请求设置超时，以防止连接挂起和资源耗尽。当请求在超时期间未收到成功响应或收到错误响应时，发送者应发出对该请求的取消通知并停止等待响应。

SDK 和其他中间件应支持为请求配置超时。

MCP 实现方可以选择在接收到对应请求的进度通知时重置超时计时器，这表明工作实际上正在进行。然而，应始终强制执行最大超时，无论进度通知如何，以降低不守规矩的一方对通信双方造成的影响。

请求超时，客户端取消请求通知示例：

{
  "jsonrpc": "2.0",
  "method": "notifications/cancelled",
  "params": {
    "requestId": 2,
    "reason": "Error: MCP error -32001: Request timed out"
  }
}

2.3.5 错误处理

MCP 实现方应准备处理以下错误情况：

协议版本不匹配
无法协商所需功能
请求超时

错误消息示例：

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "Unsupported protocol version",
    "data": {
      "supported": ["2024-11-05"],
      "requested": "1.0.0"
    }
  }
}