Documentation Index
Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt
Use this file to discover all available pages before exploring further.
模型上下文协议由几个协同工作的关键组件组成:
- 基础协议:核心 JSON-RPC 消息类型
- 生命周期管理:连接初始化、能力协商和会话控制
- 服务器功能:服务器暴露的资源、提示词和工具
- 客户端功能:客户端提供的采样和根目录列表
- 实用工具:跨领域关注点,如日志记录和参数补全
所有实现必须支持基础协议和生命周期管理组件。其他组件可以根据应用程序的具体需求来实现。
这些协议层建立了清晰的关注点分离,同时支持客户端和服务器之间的丰富交互。模块化设计允许实现仅支持它们所需的功能。
MCP 客户端和服务器之间的所有消息必须遵循 JSON-RPC 2.0 规范。该协议定义了以下类型的消息:
请求由客户端发送给服务器,反之亦然,用于发起操作。
{
jsonrpc: "2.0";
id: string | number;
method: string;
params?: {
[key: string]: unknown;
};
}
- 请求必须包含字符串或整数 ID。
- 与基础 JSON-RPC 不同,ID 不得为
null。
- 请求 ID 在同一会话中不得被请求者先前使用过。
响应作为对请求的回复发送,包含操作的结果或错误。
{
jsonrpc: "2.0";
id: string | number;
result?: {
[key: string]: unknown;
}
error?: {
code: number;
message: string;
data?: unknown;
}
}
- 响应必须包含与其对应的请求相同的 ID。
- 响应进一步细分为成功结果或错误。
result 或 error 必须设置其中一个。响应不得同时设置两者。
- 结果可以遵循任何 JSON 对象结构,而错误必须至少包含错误代码和消息。
- 错误代码必须是整数。
通知由客户端发送给服务器,反之亦然,作为单向消息。接收者不得发送响应。
{
jsonrpc: "2.0";
method: string;
params?: {
[key: string]: unknown;
};
}
批处理
JSON-RPC 还定义了一种通过数组发送来 批处理多个请求和通知 的方法。MCP 实现可以支持发送 JSON-RPC 批处理,但必须支持接收 JSON-RPC 批处理。
MCP 提供了一个用于 HTTP 的 授权 框架。使用基于 HTTP 传输的实现应该符合此规范,而使用 STDIO 传输的实现不应该遵循此规范,而是从环境中检索凭据。
此外,客户端和服务器可以协商它们自己的自定义认证和授权策略。
为了进一步讨论和贡献 MCP 认证机制的演变,请加入我们的 GitHub 讨论区,帮助塑造协议的未来!
协议的完整规范定义为 TypeScript 模式。这是所有协议消息和结构的真实来源。
还有一个 JSON 模式,它是从 TypeScript 真实来源自动生成的,用于各种自动化工具。