协议版本: draft
Model Context Protocol 由以下几个关键组件协同工作：
  • 基础协议: 核心 JSON-RPC 消息类型
  • 生命周期管理：连接初始化、能力协商以及会话控制
  • Authorization: 基于HTTP传输的认证与授权框架
  • 服务器特性: 服务器暴露的资源、提示和工具
  • 客户功能: 客户端提供的采样和根目录列表
  • 工具类: 如日志记录及参数补全等横切关注点
All implementations 必须 support the base protocol and lifecycle management components. Other components 可以 be implemented based on the specific needs of the application. 这些协议层建立了清晰的关注点分离，同时支持客户端与服务器之间的丰富交互。这种模块化设计让实现能够精确支持它们所需的功能。

​
消息

All messages between MCP clients and servers 必须 follow the JSON-RPC 2.0 specification. The protocol defines these types of messages:

​
请求

请求从客户端发送到服务器，反之亦然，以启动一个操作。 
{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
  • 请求 必须 包含一个字符串或整数ID。
  • Unlike base 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 provides an Authorization framework for use with HTTP. Implementations using an HTTP-based transport 应该 conform to this specification, whereas implementations using STDIO transport 不应 follow this specification, and instead retrieve credentials from the environment. Additionally, clients and servers 可以 negotiate their own custom authentication and authorization strategies. 关于MCP认证机制的进一步讨论与贡献计划，欢迎参与 GitHub讨论区 共同塑造协议的未来！

​
架构

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

​
通用字段

​
_meta

The _meta property/parameter is reserved by MCP to allow clients and servers to attach additional metadata to their interactions. 某些关键名称由MCP保留作为协议级别的元数据，具体如下所示; 实现不得对这些键对应的值进行假设。 此外，schema中的定义可能会保留特定名称用作目的特定的元数据，如这些定义中所声明。 键名格式： valid _meta key names have two segments: an optional 前缀, and a 名称. 前缀:
  • If specified, MUST be a series of labels separated by dots (.), followed by a slash (/).
    • 标签必须以字母开头，以字母或数字结尾；内部字符可以是字母、数字或连字符（-）。
  • Any prefix beginning with zero or more valid labels, followed by modelcontextprotocol or mcp, followed by any valid label, is 保留 for MCP use.
    • 例如：modelcontextprotocol.io/、mcp.dev/、api.modelcontextprotocol.org/和tools.mcp.com/都是保留的。
名称:
  • 除非内容为空，否则必须以字母数字字符([a-z0-9A-Z])开始和结束。
  • 可以包含连字符（-）、下划线（_）、点号（.）以及中间的数字字母字符。

​
icons

The icons property provides a standardized way for servers to expose visual identifiers for their resources, tools, prompts, and implementations. Icons enhance user interfaces by providing visual context and improving the discoverability of available functionality. Icons are represented as an array of Icon objects, where each icon includes:
  • src: A URI pointing to the icon resource (required). This can be:
    • 指向图像文件的HTTP/HTTPS URL
    • 包含base64编码图像数据的数据URI
  • mimeType: 可选的MIME类型（如果服务器类型缺失或通用）
  • sizes：可选的大小规格（例如，“48x48”，对于可缩放格式如 SVG 使用 “any”，或对于多个大小使用 “48x48 96x96”）
必须支持的MIME类型: Clients that support rendering icons 必须 support at least the following MIME types:
  • image/png - PNG 图像（安全，通用兼容性）
  • image/jpeg（以及image/jpg）- JPEG图像（安全，通用兼容性）
Clients that support rendering icons 应该 also support:
  • image/svg+xml - SVG图像（可扩展但需要注意以下所述的安全预防措施）
  • image/webp - WebP 图片（现代高效格式）
安全性考虑： Consumers of icon metadata 必须 take appropriate security precautions when handling icons to prevent compromise:
  • 将图标元数据和图标字节视为不可信的输入，并防御网络、隐私和解析风险。
  • Ensure that the icon URI is either a HTTPS or data: URI. Clients 必须 reject icon URIs that use unsafe schemes and redirects, such as javascript:, file:, ftp:, ws:, or local app URI schemes.
    • 禁止方案变更以及重定向到来源不同的主机。
  • Be resilient against resource exhaustion attacks stemming from oversized images, large dimensions, or excessive frames (e.g., in GIFs).
    • 消费者可以设定图像和内容大小的限制。
  • 无需凭据获取图标。不要发送cookies、Authorization头信息，或客户端凭据。
  • 验证图标 URI 是否与服务器同源，以最小化向第三方暴露数据或追踪信息的风险。
  • Exercise caution when fetching and rendering icons as the payload 可以 contain executable content (e.g., SVG with 嵌入式JavaScript or extended capabilities).
    • 消费者 可以 选择在渲染前禁止特定文件类型或以其他方式清理图标文件。
  • Validate MIME types and file contents before rendering. Treat the MIME type information as advisory. Detect content type via magic bytes; reject on mismatch or unknown types.
    • 维护严格的允许图像类型白名单。
用法: 图标可以附加到:
  • Implementation: MCP 服务器/客户端实现的视觉标识符
  • Tool: 工具的视觉表现
  • Prompt: 在提示模板旁显示的图标
  • Resource: 用于不同资源类型的视觉指示器
可提供多个图标以支持不同的显示情境和分辨率。客户端应根据其用户界面需求选择最合适的图标。