协议版本: draft
Model Context Protocol (MCP) 为客户端-服务器连接定义了一个严谨的生命周期，确保正确的功能协商和状态管理。
  1. 初始化: 能力协商与协议版本确认
  2. 操作: 正常协议通信
  3. 关机: 该连接的优雅终止

​
生命周期阶段

​
初始化

初始化阶段 必须 是客户端与服务器之间的首次交互。 在此阶段，客户端和服务器：
  • 建立协议版本兼容性
  • 交换和协商能力
  • 共享实现细节
客户端 必须 通过发送一个包含如下内容的 initialize 请求来启动此阶段：
  • 支持的协议版本
  • 客户端能力
  • 客户端实现信息
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "roots": {
        "listChanged": true
      },
      "sampling": {},
      "elicitation": {}
    },
    "clientInfo": {
      "name": "ExampleClient",
      "title": "Example Client Display Name",
      "version": "1.0.0",
      "icons": [
        {
          "src": "https://example.com/icon.png",
          "mimeType": "image/png",
          "sizes": "48x48"
        }
      ],
      "websiteUrl": "https://example.com"
    }
  }
}
服务器必须以自身能力和信息进行响应： 
{
  "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",
      "title": "Example Server Display Name",
      "version": "1.0.0",
      "icons": [
        {
          "src": "https://example.com/server-icon.svg",
          "mimeType": "image/svg+xml",
          "sizes": "any"
        }
      ],
      "websiteUrl": "https://example.com/server"
    },
    "instructions": "Optional instructions for the client"
  }
}
成功初始化之后，客户端必须发送一个initialized通知来表明它已准备好开始正常操作： 
{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}
  • 客户端不应该在服务器响应initialize请求之前，除了pings之外发送其他请求。
  • 服务器在收到 initialized 通知之前，不应发送除 pings 和 日志记录 之外的其他请求。

​
版本协商

在initialize请求中，客户端必须发送其支持的协议版本。 这应该是客户端支持的最新版本。 如果服务器支持请求的协议版本，它必须回应相同的版本。否则，服务器必须回应它所支持的另一个协议版本。这应该是服务器支持的最新版本。 如果客户端不支持服务器响应中的版本，它应该断开连接。
如果使用HTTP, 客户端 必须 在所有后续向MCP服务器的请求中包含 MCP-Protocol-Version: HTTP头。 详情请参阅 传输中的协议版本头部分。

​
能力协商

客户端与服务器通过能力协商机制确定会话期间可用的可选协议功能。 主要功能包括: prompts
类别能力描述
客户端roots提供文件系统根目录的能力
客户端采样支持语言模型 sampling 请求
客户端激发支持服务器启发式请求
客户端实验性的描述对非标准实验特性的支持情况
服务器提供 提示模版
服务器resources提供可读的 resources
服务器工具暴露可调用的工具
服务器日志发送结构化日志消息
服务器completions支持参数 autocompletion 功能
服务器实验性的描述对非标准实验性功能的支持
能力对象可以描述如下子能力：
  • listChanged: 支持列表变更通知（适用于提示、资源和工具）
  • subscribe: 支持订阅单个项目的变更（仅限资源）

​
操作

在操作阶段，客户端与服务器根据协商的能力交换消息。 双方 必须:
  • 遵守协商的协议版本
  • 仅使用已成功协商的功能

​
关机

在关闭阶段，一方（通常是客户端）会干净利落地终止协议连接。未定义特定的关闭消息——而是应使用底层传输机制来发出连接终止信号：

​
标准输入输出

对于标准输入输出 transport，客户端应该通过以下方式发起关闭：
  1. 首先，关闭子进程（服务器）的输入流
  2. 等待服务器退出，或在合理时间内未退出则发送SIGTERM
  3. 如果服务器在SIGTERM后的合理时间内未退出，则发送SIGKILL
服务器 可以 通过关闭其输出流向客户端并退出来发起关闭。

​
超文本传输协议

对于 HTTP transports，关闭相关 HTTP 连接即表示关机。

​
超时设置

Implementations 应该 为所有发送的请求设置超时时间，以防止连接挂起和资源枯竭。当请求在超时期间内未收到成功或错误响应时，发送方 应该 为该请求发出一个cancellation notification 并停止等待响应。 SDK以及其他中间件应该允许在每个请求基础上对这些超时进行配置。 实施方 可以 选择在收到与请求对应的进度通知时重置超时时钟，因为这意味着实际工作正在进行。但实施方 应该 始终强制执行最大超时限制，无论是否有进度通知，以限制行为异常的客户端或服务器的影响。

​
错误处理

实现方案应该准备好处理以下错误情况:
  • 协议版本不匹配
  • 未能协商所需能力
  • 请求 timeouts
初始化错误示例： 
{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "Unsupported protocol version",
    "data": {
      "supported": ["2024-11-05"],
      "requested": "1.0.0"
    }
  }
}