概述

• 基础协议（Base Protocol）：核心的 JSON-RPC 消息类型
• 版本管理与兼容性（Versioning and Compatibility）：协议版本协商、扩展协商，以及与早期协议修订版的互操作性
• 消息模式（Message Patterns）：核心协议所支持的消息传递模式，包括请求与响应、多轮往返请求（MRTR），以及订阅与通知
• 授权（Authorization）：用于基于 HTTP 的传输的认证和授权框架
• 服务器特性（Server Features）：由服务器暴露的资源、提示和工具
• 客户端特性（Client Features）：由客户端提供的征询、采样和根目录列表
• 实用工具（Utilities）：诸如日志记录和参数补全之类的横切关注点

​

消息

​

请求

{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

• 请求**必须（MUST）**包含一个字符串或整数 ID。
• 与基础 JSON-RPC 不同，ID **不得（MUST NOT）**为 null。
• 请求 ID **不得（MUST NOT）**与发送方已发出且尚未收到响应的任何其他请求的 ID 相同。

​

响应

​

结果响应

{
  jsonrpc: "2.0";
  id: string | number;
  result: {
    resultType: string;
    [key: string]: unknown;
  };
}

• 结果响应**必须（MUST）**包含与它们所对应的请求相同的 ID。
• 结果响应**必须（MUST）**包含一个 result 字段。
• result **可以（MAY）**遵循任何 JSON 对象结构。
• result **必须（MUST）**包含一个 resultType 字段以指示结果的类型。

ResultType

• resultType 为 "complete" 表示请求成功完成，且结果包含最终内容。
• resultType 为 "input_required" 表示请求未完成，需要更多信息来处理该请求。结果包含一个带有所需额外信息的 InputRequiredResult 对象。
• 扩展**可以（MAY）添加额外的 ResultType 值。所支持的 ResultType 值集合必须（MUST）**从核心协议中定义的集合创建，并包含通过能力公布的所支持扩展的任何额外值。
• 客户端无法识别的任何 resultType 值**必须（MUST）**被视为无效。
• 为了与实现早期协议版本、不包含 resultType 的服务器向后兼容，客户端**必须（MUST）**将缺失的 resultType 视为 "complete"。

​

错误响应

{
  jsonrpc: "2.0";
  id?: string | number;
  error: {
    code: number;
    message: string;
    data?: unknown;
  }
}

• 错误响应**必须（MUST）**包含与它们所对应的请求相同的 ID（除了由于请求格式错误而无法读取 ID 的错误情况）。
• 错误响应**必须（MUST）**包含一个带有 code 和 message 的 error 字段。
• 错误代码**必须（MUST）**是整数。
• 错误响应**可以（MAY）**包含一个带有任何类型额外信息（例如嵌套错误）的 data 成员。

​

错误代码

• -32000 到 -32019 —— 遗留（legacy）。 此子范围内的代码是在本策略引入之前由实现分配的。**不得（MUST NOT）在此子范围内分配新代码，且新的实现完全不应（SHOULD NOT）使用此子范围内的代码。除了 -32002（见下文）之外，接收方不得（MUST NOT）**假定这些代码有任何特定含义。
• -32020 到 -32099 —— 为 MCP 规范保留。 此子范围内的错误代码专由 MCP 规范定义，并记录在 schema 中。实现**不得（MUST NOT）发出此子范围内任何未由本规范定义的代码，并必须（MUST）**仅以其指定的含义使用已定义的代码。

• -32002 —— 资源未找到（2025-11-25 及更早版本；由 -32602 替换）。客户端**应当（SHOULD）**仍接受来自实现早期版本的服务器的 -32002。
• -32042 —— 需要 URL 征询（仅 2025-11-25）。

​

通知

{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

• 通知**不得（MUST NOT）**包含 ID。

​

消息模式

1. 请求与响应：客户端向服务器发送请求，服务器以结果或错误响应。
2. 多轮往返请求（MRTR）：服务器需要额外的客户端输入（采样、征询或 roots）来完成一个请求。
3. 订阅与通知：客户端订阅来自服务器的通知流，这些通知在发生时被发送。

​

无状态性

• 服务器**不得（MUST NOT）**依赖同一连接上的先前请求来建立上下文（例如能力、协议版本、客户端身份）。每个请求都在其 _meta 字段中提供这些元数据。
• 服务器**应当（SHOULD）**准备好处理与多个任务、线程或对话关联的请求。
• 服务器**不应（SHOULD NOT）**要求客户端重用同一连接或进程来执行相关操作。
• 客户端**不应（SHOULD NOT）**将单个任务、线程或对话用作 stdio 进程的生命周期边界。
• 需要跨多个请求的状态（例如长时运行的任务、应用级句柄）**必须（MUST）**由客户端在每个请求上传递的显式标识符来引用。

​

认证

​

Schema

​

JSON Schema 用法

​

Schema 方言

1. 默认方言：当一个 schema 不包含 $schema 字段时，它默认为 JSON Schema 2020-12
2. 显式方言：schema 可以（MAY）包含一个 $schema 字段以指定一个不同的方言
3. 支持的方言：实现必须（MUST）至少支持 2020-12，并应当（SHOULD）记录它们额外支持哪些方言
4. 建议：推荐（RECOMMENDED）实现者使用 JSON Schema 2020-12。

​

用法示例

​

默认方言（2020-12）：

{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "integer", "minimum": 0 }
  },
  "required": ["name"]
}

​

显式方言（draft-07）：

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "integer", "minimum": 0 }
  },
  "required": ["name"]
}

​

实现要求

• 对于没有显式 $schema 字段的 schema，客户端和服务器**必须（MUST）**支持 JSON Schema 2020-12
• 客户端和服务器**必须（MUST）根据其声明的或默认的方言来校验 schema。它们必须（MUST）**通过返回一个指示不支持该方言的适当错误，优雅地处理不受支持的方言。
• 客户端和服务器**应当（SHOULD）**记录它们支持哪些 schema 方言

​

Schema 校验

• Schema **必须（MUST）**根据其声明的或默认的方言有效

​

$ref 解析

​

组合关键字资源使用

​

通用字段

​

_meta

• 如果指定，必须（MUST）是由点（.）分隔的一系列标签，后跟一个斜杠（/）。
  • 标签必须（MUST）以字母开头并以字母或数字结尾；内部字符可以是字母、数字或连字符（-）。
  • 实现应当（SHOULD）使用反向 DNS 表示法（例如 com.example/ 而非 example.com/）。
• 任何第二个标签为 modelcontextprotocol 或 mcp 的前缀都为 MCP 使用而保留。
  • 例如：io.modelcontextprotocol/、dev.mcp/、org.modelcontextprotocol.api/ 和 com.mcp.tools/ 都是保留的。
  • 然而，com.example.mcp/ 不保留，因为第二个标签是 example。

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

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "New York"
    },
    "_meta": {
      "traceparent": "00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01"
    }
  }
}

​

icons

• src：指向图标资源的 URI（必需）。这可以是：
  • 指向图像文件的 HTTP/HTTPS URL
  • 带有 base64 编码图像数据的 data URI
• mimeType：可选的 MIME 类型，用于服务器类型缺失或通用的情况
• sizes：可选的尺寸规格数组（例如 ["48x48"]，对于像 SVG 这样的可缩放格式用 ["any"]，或对于多个尺寸用 ["48x48", "96x96"]）
• theme：可选的图标背景主题偏好（light 或 dark）

• image/png —— PNG 图像（安全、通用兼容）
• image/jpeg（和 image/jpg）—— JPEG 图像（安全、通用兼容）

• image/svg+xml —— SVG 图像（可缩放，但需要如下所述的安全预防措施）
• image/webp —— WebP 图像（现代、高效的格式）

• 将图标元数据和图标字节视为不受信任的输入，并防御网络、隐私和解析风险。
• 确保图标 URI 是 HTTPS 或 data: URI。客户端**必须（MUST）**拒绝使用不安全的 scheme 和重定向的图标 URI，例如 javascript:、file:、ftp:、ws: 或本地应用 URI scheme。
  • 不允许 scheme 变更和到不同 origin 主机的重定向。
• 对源于过大图像、大尺寸或过多帧（例如 GIF 中）的资源耗尽攻击保持有韧性。
  • 消费者**可以（MAY）**为图像和内容大小设置限制。
• 在不带凭据的情况下获取图标。不要发送 cookie、Authorization header 或客户端凭据。
• 验证图标 URI 与服务器同源。这最小化了向第三方暴露数据或跟踪信息的风险。
• 在获取和渲染图标时保持谨慎，因为负载**可以（MAY）**包含可执行内容（例如带有嵌入 JavaScript 或扩展能力的 SVG）。
  • 消费者**可以（MAY）**选择不允许特定的文件类型，或在渲染前以其他方式净化图标文件。
• 在渲染前校验 MIME 类型和文件内容。将 MIME 类型信息视为建议性的。通过魔术字节（magic bytes）检测内容类型；在不匹配或未知类型时拒绝。
  • 维护一个严格的图像类型 allowlist。

• Implementation：MCP 服务器/客户端实现的视觉标识符
• Tool：工具功能的视觉表示
• Prompt：与提示模板一起显示的图标
• Resource：不同资源类型的视觉指示器