Skip to main content
模型上下文协议由几个关键组件组成,它们协同工作:
  • 基础协议:核心 JSON-RPC 消息类型
  • 生命周期管理:连接初始化、能力协商和会话控制
  • 授权:基于 HTTP 的传输的身份验证和授权框架
  • 服务器功能:服务器暴露的资源、提示词和工具
  • 客户端功能:客户端提供的采样和根目录列表
  • 实用工具:日志记录和参数补全等横切关注点
所有实现必须支持基础协议和生命周期管理组件。其他组件可以根据应用程序的具体需求来实现。 这些协议层建立了清晰的关注点分离,同时支持客户端和服务器之间的丰富交互。模块化设计允许实现仅支持它们所需的功能。

消息

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。
  • 响应进一步细分为成功结果错误resulterror 必须设置其中一个。响应不得同时设置两者。
  • 结果可以遵循任何 JSON 对象结构,而错误必须至少包含错误代码和消息。
  • 错误代码必须是整数。

通知

通知由客户端发送给服务器,或由服务器发送给客户端,作为单向消息。接收者不得发送响应。
{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
  • 通知不得包含 ID。

授权

MCP 提供了一个用于 HTTP 的 授权 框架。使用基于 HTTP 的传输的实现应该符合此规范,而使用 STDIO 传输的实现不应该遵循此规范,而是从环境中检索凭据。 此外,客户端和服务器可以协商它们自己的自定义身份验证和授权策略。 为了进一步讨论和贡献 MCP 认证机制的演变,请加入我们的 GitHub 讨论区,帮助塑造协议的未来!

模式

协议的完整规范定义为 TypeScript 模式。这是所有协议消息和结构的唯一事实来源。 还有一个 JSON 模式,它是从 TypeScript 唯一事实来源自动生成的,用于各种自动化工具。

通用字段

_meta

_meta 属性/参数由 MCP 保留,允许客户端和服务器在其交互中附加额外的元数据。 某些键名由 MCP 保留用于协议级元数据,如下所示;实现不得对这些键处的值做出假设。 此外,模式 中的定义可能会为特定用途的元数据保留特定名称,如这些定义中所述。 键名格式: 有效的 _meta 键名有两个部分:一个可选的前缀和一个名称 前缀:
  • 如果指定,必须是一系列由点(.)分隔的标签,后跟一个斜杠(/)。
    • 标签必须以字母开头,以字母或数字结尾;内部字符可以是字母、数字或连字符(-)。
  • 任何以零个或多个有效标签开头,后跟 modelcontextprotocolmcp,再后跟任何有效标签的前缀,均保留供 MCP 使用。
    • 例如:modelcontextprotocol.io/mcp.dev/api.modelcontextprotocol.org/tools.mcp.com/ 均被保留。
名称:
  • 除非为空,否则必须以字母数字字符([a-z0-9A-Z])开头和结尾。
  • 中间可以包含连字符(-)、下划线(_)、点(.)和字母数字字符。