概述
协议版本: 2025-06-18
模型上下文协议由几个协同工作的关键组件组成:
- 基础协议:核心 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。
- 响应进一步细分为成功结果或错误。必须设置
result或error之一。响应不得同时设置两者。 - 结果可以遵循任何 JSON 对象结构,而错误必须至少包括错误代码和消息。
- 错误代码必须为整数。
通知
通知从客户端发送到服务器,或从服务器发送到客户端,作为单向消息。接收方不得发送响应。
{
jsonrpc: "2.0";
method: string;
params?: {
[key: string]: unknown;
};
}- 通知不得包括 ID。
授权
MCP 提供了用于 HTTP 的授权框架。使用基于 HTTP 的传输的实现应该遵循此规范,而使用标准输入输出传输的实现不应该遵循此规范,而应从环境中检索凭据。
此外,客户端和服务器可以协商自己的自定义身份验证和授权策略。
要进一步讨论和贡献 MCP 授权机制的演变,请加入我们的 GitHub 讨论 帮助塑造协议的未来!
Schema
协议的完整规范定义为 TypeScript schema。这是所有协议消息和结构的真实来源。
还有一个 JSON Schema,它是从 TypeScript 真实源自动生成的,用于各种自动化工具。
通用字段
_meta
MCP 保留 _meta 属性/参数,以允许客户端和服务器为其交互附加额外的元数据。
MCP 为协议级元数据保留某些键名,如下所述;实现不得对这些键的值做出假设。
此外,schema 中的定义可以为特定于目的的元数据保留特定名称,如这些定义中所声明的那样。
键名格式: 有效的 _meta 键名有两个段:可选的前缀和名称。
前缀:
- 如果指定,必须是由点(
.)分隔的标签系列,后跟斜杠(/)。- 标签必须以字母开头并以字母或数字结尾;内部字符可以是字母、数字或连字符(
-)。
- 标签必须以字母开头并以字母或数字结尾;内部字符可以是字母、数字或连字符(
- 以零个或多个有效标签开头,后跟
modelcontextprotocol或mcp,再后跟任何有效标签的任何前缀都被保留供 MCP 使用。- 例如:
modelcontextprotocol.io/、mcp.dev/、api.modelcontextprotocol.org/和tools.mcp.com/都被保留。
- 例如:
名称:
- 除非为空,必须以字母数字字符(
[a-z0-9A-Z])开头和结尾。 - 可以在中间包含连字符(
-)、下划线(_)、点(.)和字母数字。