协议版本: draft
Model Context Protocol 由以下几个关键组件协同工作：
  • 基础协议: 核心 JSON-RPC 消息类型
  • 生命周期管理：连接初始化、能力协商以及会话控制
  • Authorization: 基于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。
  • Responses are further sub-categorized as either 成功的结果 or 错误. Either a result or an error 必须 be set. A response 不可 set both.
  • 结果可以遵循任意JSON对象结构，而错误必须至少包含错误代码和消息。
  • 错误码必须为整数。

​
通知

通知以单向消息的形式从客户端发送到服务器，或者反之。 接收方禁止发送响应。 
{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
  • 通知不得包含ID。

​
认证

MCP 提供了一个用于 HTTP 的 Authorization 框架。 使用基于 HTTP 传输的实现应该遵循此规范， 而使用 STDIO 传输的实现不应遵循此规范， 而是应该从环境中获取凭据。 此外，客户端和服务端可以协商自定义的身份验证和授权策略。 关于MCP认证机制的进一步讨论与贡献计划，欢迎参与 GitHub讨论区 共同塑造协议的未来！

​
架构

该协议的完整规范被定义为一个 TypeScript架构。 这是所有协议消息和架构的真实来源。 还有一个 JSON Schema， 它从 TypeScript 的源数据自动生成，用于各种自动化工具。

​
通用字段

​
_meta

属性/参数 _meta 由 MCP 保留，允许客户端和服务器在其交互中附加额外的元数据。 某些关键名称由MCP保留作为协议级别的元数据，具体如下所示; 实现不得对这些键对应的值进行假设。 此外，schema中的定义可能会保留特定名称用作目的特定的元数据，如这些定义中所声明。 键名格式： 有效的 _meta 键名包含两个部分：一个可选的 前缀，和一个 名称。 前缀:
  • 如果指定了，必须是由点号（.）分隔的一系列标签，后跟一个斜杠（/）。
    • 标签必须以字母开头，以字母或数字结尾；内部字符可以是字母、数字或连字符（-）。
  • 任何以前缀开始，包含零个或多个有效标签，后面跟着modelcontextprotocol或mcp，再加上任意有效标签，都为MCP使用保留。
    • 例如：modelcontextprotocol.io/、mcp.dev/、api.modelcontextprotocol.org/和tools.mcp.com/都是保留的。
名称:
  • 除非内容为空，否则必须以字母数字字符([a-z0-9A-Z])开始和结束。
  • 可以包含连字符（-）、下划线（_）、点号（.）以及中间的数字字母字符。

​
icons

icons 属性为服务器提供了一种标准化的方式，用于暴露其资源、工具、提示和实现的视觉标识符。图标通过提供视觉上下文和增强现有功能的可发现性来改进用户界面。 图标表示为Icon对象的数组, 其中每个图标包括:
  • src: 指向图标资源的URI（必需）。可以是：
    • 指向图像文件的HTTP/HTTPS URL
    • 包含base64编码图像数据的数据URI
  • mimeType: 可选的MIME类型（如果服务器类型缺失或通用）
  • sizes：可选的大小规格（例如，“48x48”，对于可缩放格式如 SVG 使用 “any”，或对于多个大小使用 “48x48 96x96”）
必须支持的MIME类型: 支持渲染图标的客户端必须至少支持以下MIME类型：
  • 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中）导致的资源耗尽攻击。
    • 消费者可以设定图像和内容大小的限制。
  • 无需凭据获取图标。不要发送cookies、Authorization头信息，或客户端凭据。
  • 验证图标 URI 是否与服务器同源，以最小化向第三方暴露数据或追踪信息的风险。
  • 提取和渲染图标时需谨慎，因为有效载荷可以包含可执行内容（例如，带有嵌入式JavaScript或extended capabilities的SVG）。
    • 消费者可以选择在渲染前禁止特定文件类型或以其他方式清理图标文件。
  • 在渲染前验证MIME类型和文件内容。将MIME类型信息视为建议性参考。通过魔数字节检测内容类型；在不匹配或未知类型时拒绝处理。
    • 维护严格的允许图像类型白名单。
用法: 图标可以附加到:
  • Implementation: MCP 服务器/客户端实现的视觉标识符
  • Tool: 工具的视觉表现
  • Prompt: 在提示模板旁显示的图标
  • Resource: 用于不同资源类型的视觉指示器
可提供多个图标以支持不同的显示情境和分辨率。客户端应根据其用户界面需求选择最合适的图标。