概述

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

​

消息

​

请求 (Requests)

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

• 请求必须包含一个字符串或整数类型的 ID。
• 与基础 JSON-RPC 不同，ID 不得为 null。
• 请求 ID 在同一会话内不得被请求者重复使用。

​

响应 (Responses)

​

结果响应 (Result Responses)

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

• 结果响应必须包含与其对应的请求相同的 ID。
• 结果响应必须包含一个 result 字段。
• result 可以遵循任何 JSON 对象结构。

​

错误响应 (Error Responses)

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

• 错误响应必须包含与其对应的请求相同的 ID（除非在由于请求格式错误而无法读取 ID 的错误情况下）。
• 错误响应必须包含一个带有 code 和 message 的 error 字段。
• 错误代码必须为整数。

​

通知

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

• 通知不得包含 ID。

​

认证 (Auth)

​

架构 (Schema)

​

JSON Schema 使用

​

Schema 方言 (Dialect)

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

​

使用示例

​

默认方言 (2020-12)

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

​

显式方言 (draft-07)

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

​

实现要求

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

​

Schema 验证

• 架构必须根据其声明或默认的方言有效

​

通用字段

​

_meta

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

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

​

图标 (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。客户端必须拒绝使用不安全方案和重定向的图标 URI，例如 javascript:、file:、ftp:、ws: 或本地应用 URI 方案。
  • 禁止方案更改以及重定向到不同源的主机。
• 防御源自超大图像、大尺寸或过多帧（例如在 GIF 中）的资源耗尽攻击。
  • 使用者可以为图像和内容大小设置限制。
• 获取图标时不带凭据。不要发送 cookie、Authorization 标头或客户端凭据。
• 验证图标 URI 是否与服务器来自同一源。这最大限度地减少了向第三方泄露数据或跟踪信息的风险。
• 获取和渲染图标时要格外小心，因为载荷可能包含可执行内容（例如带有 嵌入式 JavaScript 或 扩展功能 的 SVG）。
  • 使用者可以选择禁止特定文件类型，或在渲染前对图标文件进行清理。
• 在渲染前验证 MIME 类型和文件内容。将 MIME 类型信息视为参考。通过魔数 (magic bytes) 检测内容类型；在不匹配或类型未知时予以拒绝。
  • 维护一份严格的图像类型允许列表。

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