在开发前，首先带大家熟悉一下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）。