模型上下文协议（MCP）为客户端-服务器连接定义了严格的生命周期，确保能力协商与状态管理的规范性：
- 初始化阶段：进行能力协商并确定协议版本运行阶段：正常的协议通信终止阶段：连接的优雅关闭
初始化阶段（Initialization）
初始化阶段必须是客户端与服务器的首次交互。在此阶段，双方需完成以下操作：
- 确认协议版本兼容性交换并协商支持的能力共享实现细节
客户端必须通过发送初始化 (initialize) 请求来启动该阶段，请求中需包含以下内容：
- 支持的协议版本客户端能力列表客户端实现信息
{ "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" }}成功初始化后，客户端必须发送一个初始化通知 (initialized notification)，表明已准备好开始正常操作:
{ "jsonrpc": "2.0", "method": "notifications/initialized"}- 在服务器响应初始化请求之前，客户端不应发送除心跳检测（ping）之外的任何请求。在收到初始化通知之前，服务器不应发送除心跳检测（ping）和日志记录之外的任何请求。
版本协商（Version Negotiation）
在初始化请求中，客户端必须发送其支持的协议版本，且该版本应为客户端支持的最新版本。
如果服务器支持客户端请求的协议版本，则必须返回相同版本；否则，服务器必须返回其支持的另一个协议版本（通常应为服务器支持的最新版本）。
若客户端不支持服务器返回的版本，则应断开连接。
能力协商（Capability Negotiation）
客户端与服务器能力协商确定会话期间可用的可选协议功能
关键能力包括：
| Category | Capability | Description |
|---|---|---|
| Client | roots | 提供文件系统根目录的能力 |
| Client | sampling | 支持LLM采样请求 |
| Client | experimental | 支持非标准实验性功能的说明 |
| Server | prompts | 提供提示词模版 |
| Server | resources | 提供可读资源 |
| Server | tools | 暴露可调用工具 |
| Server | logging | 生成结构化日志消息 |
| Server | experimental | 支持非标准实验性功能的说明 |
能力对象可描述以下子功能：
- listChanged：支持列表变更通知（适用于提示词、资源和工具）subscribe：支持订阅单个项目的变更（仅限资源）
运行阶段（Operation）
在运行阶段，客户端与服务器将根据协商确定的能力进行消息交互。
双方应当遵循以下准则：
- 严格遵守协商达成的协议版本仅使用已成功协商通过的功能
终止阶段（Shutdown）
在终止阶段，通常由客户端主动关闭协议连接。
无需定义特定的终止消息——直接通过底层传输机制发出连接终止信号即可。
stdio
在使用标准输入输出传输时，应按以下流程终止连接：
- 首先关闭子进程（服务端）的输入流等待服务端退出，若未在合理时间内退出则发送SIGTERM信号发送SIGTERM后若仍未及时退出，则发送SIGKILL信号
服务端可通过关闭向客户端的输出流并退出来主动终止连接。
HTTP
对于HTTP传输协议，终止流程通过关闭相关HTTP连接实现。
超时（Timeouts）
所有实现方案均应设置请求超时机制，以避免连接挂起和资源耗尽。当请求在超时期限内未收到成功或错误响应时，发送方应当发送该请求的取消通知以及停止等待响应。
SDK及中间件应支持按请求单独配置超时参数。
实现方案可选择在收到请求对应的进度通知时重置超时计时器（这表明处理仍在进行）。但无论收到多少进度通知，实现方案都应设置最终超时上限，以限制异常客户端或服务端的影响。
异常处理（Error Handing）
实现方案应妥善处理以下异常场景：
- 协议版本不匹配必需能力协商失败请求超时
初始化错误示例：
{ "jsonrpc": "2.0", "id": 1, "error": { "code": -32602, "message": "Unsupported protocol version", "data": { "supported": ["2024-11-05"], "requested": "1.0.0" } }}