鸭梨公共文档

主题

概述 ​

协议修订版本：2025-06-18

Model Context Protocol 由几个关键组件组成，这些组件协同工作：

  • 基础协议: 核心 JSON-RPC 消息类型
  • 生命周期管理: 连接初始化、能力协商和会话控制
  • 授权: 基于 HTTP 传输的身份验证和授权框架
  • 服务器功能: 服务器公开的资源、提示和工具
  • 客户端功能: 客户端提供的采样和根目录列表
  • 实用工具: 跨领域关注点，如日志记录和参数补全

所有实现必须支持基础协议和生命周期管理组件。其他组件可以根据应用程序的具体需求进行实现。

这些协议层建立了清晰的关注点分离，同时实现了客户端和服务器之间的丰富交互。模块化设计允许实现恰好支持它们所需的功能。

1. 消息 ​

MCP 客户端和服务器之间的所有消息必须遵循 JSON-RPC 2.0 规范。协议定义了以下类型的消息：

1.1 请求 ​

请求从客户端发送到服务器或反之，以启动操作。

typescript
{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
  • 请求必须包含字符串或整数 ID。
  • 与基础 JSON-RPC 不同，ID 不得为 null。
  • 请求 ID 不得在同一会话中被请求者先前使用过。

1.2 响应 ​

响应作为对请求的回复发送，包含操作的结果或错误。

typescript
{
  jsonrpc: "2.0";
  id: string | number;
  result?: {
    [key: string]: unknown;
  }
  error?: {
    code: number;
    message: string;
    data?: unknown;
  }
}
  • 响应必须包含与其对应请求相同的 ID。
  • 响应进一步细分为成功结果或错误。必须设置 result 或 error 中的一个。响应不得同时设置两者。
  • 结果可以遵循任何 JSON 对象结构，而错误必须至少包含错误代码和消息。
  • 错误代码必须是整数。

1.3 通知 ​

通知从客户端发送到服务器或反之，作为单向消息。接收者不得发送响应。

typescript
{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
  • 通知不得包含 ID。

2. 授权 ​

MCP 为 HTTP 使用提供了授权框架。使用基于 HTTP 传输的实现应该符合此规范，而使用 STDIO 传输的实现不应该遵循此规范，而应该从环境中检索凭据。

此外，客户端和服务器可以协商自己的自定义身份验证和授权策略。

关于 MCP 认证机制演进的进一步讨论和贡献，请加入我们在 GitHub Discussions 的讨论，帮助塑造协议的未来！

3. 模式 ​

协议的完整规范定义为 TypeScript 模式。这是所有协议消息和结构的权威来源。

还有一个 JSON Schema，它是从 TypeScript 权威来源自动生成的，用于各种自动化工具。

3.1 通用字段 ​

3.1.1 _meta ​

_meta 属性/参数由 MCP 保留，允许客户端和服务器在其交互中附加额外的元数据。

某些键名由 MCP 保留用于协议级元数据，如下所述；实现不得对这些键的值做出假设。

此外，模式中的定义可能为特定目的的元数据保留特定名称，如这些定义中所声明的。

键名格式： 有效的 _meta 键名有两个部分：可选的前缀和名称。

前缀：

  • 如果指定，必须是由点（.）分隔的一系列标签，后跟斜杠（/）。
    • 标签必须以字母开头，以字母或数字结尾；内部字符可以是字母、数字或连字符（-）。
  • 任何以零个或多个有效标签开头的前缀，后跟 modelcontextprotocol 或 mcp，再后跟任何有效标签，都保留给 MCP 使用。
    • 例如：modelcontextprotocol.io/、mcp.dev/、api.modelcontextprotocol.org/ 和 tools.mcp.com/ 都是保留的。

名称：

  • 除非为空，必须以字母数字字符（[a-z0-9A-Z]）开头和结尾。
  • 可以在中间包含连字符（-）、下划线（_）、点（.）和字母数字字符。