在开发前，首先带大家熟悉一下MCP协议的消息格式，和所有可能需要进行协商的功能：
- MCP协议通过JSON-RPC 2.0规范定义了请求、响应和通知三种消息类型，确保通信的标准化和一致性。
- 能力协商机制使客户端和服务器能够动态确定支持的协议功能，提升协议的灵活性和扩展性。
- 子能力的引入进一步细化了功能支持，满足更复杂的应用场景需求。
通过这些机制，MCP协议实现了高效、灵活且可扩展的通信能力，适用于多样化的应用场景。
消息格式
在MCP（Message Communication Protocol）中，所有消息都必须遵循JSON-RPC 2.0规范。该协议定义了三种类型的消息：请求（Requests）、响应（Responses）和通知（Notifications）。
请求（Requests）
请求可以从客户端发送到服务器，也可以从服务器发送到客户端。请求的格式如下：
{
"jsonrpc": "2.0",
"id": "string | number",
"method": "string",
"params": {
"[key: string]": "unknown"
}
}
- 请求必须包含一个字符串或整数类型的ID。
- 与基础的JSON-RPC不同，ID不能为null。
- 请求ID在同一会话中不能被重复使用。
响应（Responses）
响应是对请求的回复，其格式如下：
{
"jsonrpc": "2.0",
"id": "string | number",
"result": {
"[key: string]": "unknown"
},
"error": {
"code": "number",
"message": "string",
"data": "unknown"
}
}
- 响应必须包含与对应请求相同的ID。
- 响应必须设置
result或error之一，但不能同时设置两者。 - 错误代码必须为整数。
通知（Notifications）
通知可以从客户端发送到服务器，也可以从服务器发送到客户端，且不期望得到回复。通知的格式如下：
{
"jsonrpc": "2.0",
"method": "string",
"params": {
"[key: string]": "unknown"
}
}
- 通知不能包含ID。
能力协商
在会话开始时，客户端（Client）和服务器（Server）通过能力协商确定哪些可选的协议功能将被启用。以下是关键能力及其描述：
| 类别 | 能力 | 描述 |
|---|---|---|
| Client | roots | 提供文件系统根目录的能力 |
| Client | sampling | 支持LLM（大语言模型）采样请求 |
| Client | experimental | 支持非标准的实验性功能 |
| Server | prompts | 提供提示模板（prompt templates） |
| Server | resources | 提供可读资源 |
| Server | tools | 暴露可调用的工具 |
| Server | logging | 发送结构化日志消息 |
| Server | experimental | 支持非标准的实验性功能 |
能力对象（Capability objects）还可以描述子能力，例如：
- listChanged：支持列表变更通知（适用于prompts、resources和tools）。
- subscribe：支持订阅单个项目的变更（仅适用于resources）。
总结
本文详细介绍了MCP（Message Communication Protocol）协议的核心内容，包括消息格式和能力协商机制，所有消息均遵循JSON-RPC 2.0规范。
消息类型
- 请求（Requests）：客户端与服务器之间发送的消息，必须包含唯一ID，且ID不能为null或重复使用。
- 响应（Responses）：对请求的回复，必须包含与请求相同的ID，并返回结果（result）或错误（error），但不能同时设置两者。
- 通知（Notifications）：客户端与服务器之间发送的消息，不期望回复，且不能包含ID。
能力协商
客户端和服务器在会话初期通过能力协商确定可用的协议功能，关键能力包括：
- 客户端能力：文件系统支持（roots）、LLM采样（sampling）、实验性功能（experimental）。
- 服务器能力：提示模板（prompts）、资源管理（resources）、工具调用（tools）、日志记录（logging）、实验性功能（experimental）。
- 子能力：如列表变更通知（listChanged）和资源订阅（subscribe）。