> ## Documentation Index
> Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 概述

<div id="enable-section-numbers" />

模型上下文协议（Model Context Protocol）由几个关键组件组成，它们协同工作：

* **基础协议**：核心 JSON-RPC 消息类型
* **生命周期管理**：连接初始化、能力协商和
  会话控制
* **授权**：基于 HTTP 的传输的认证和授权框架
* **服务器功能**：服务器暴露的资源、提示词和工具
* **客户端功能**：客户端提供的采样和根目录列表
* **工具实用程序**：横切关注点，如日志记录和参数补全

所有实现 **必须** 支持基础协议和生命周期管理
组件。其他组件 **可以** 根据应用程序的具体需求进行实现。

这些协议层建立了清晰的关注点分离，同时支持客户端和服务器之间丰富的
交互。模块化设计允许实现仅支持它们确切需要的功能。

## 消息

MCP 客户端和服务器之间的所有消息 **必须** 遵循
[JSON-RPC 2.0](https://www.jsonrpc.org/specification) 规范。协议定义了
这些类型的消息：

### 请求

[请求](/specification/2025-11-25/schema#jsonrpcrequest) 由客户端发送给服务器，反之亦然，以启动操作。

```typescript theme={null}
{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
```

* 请求 **必须** 包含字符串或整数 ID。
* 与基础 JSON-RPC 不同，ID **不得** 为 `null`。
* 请求 ID **不得** 在同一会话中被请求者先前使用过。

### 响应

响应作为对请求的回复发送，包含操作的结果或错误。

#### 结果响应

[结果响应](/specification/2025-11-25/schema#jsonrpcresultresponse) 在操作成功完成时发送。

```typescript theme={null}
{
  jsonrpc: "2.0";
  id: string | number;
  result: {
    [key: string]: unknown;
  }
}
```

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

#### 错误响应

[错误响应](/specification/2025-11-25/schema#jsonrpcerrorresponse) 在操作失败或遇到错误时发送。

```typescript theme={null}
{
  jsonrpc: "2.0";
  id?: string | number;
  error: {
    code: number;
    message: string;
    data?: unknown;
  }
}
```

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

### 通知

[通知](/specification/2025-11-25/schema#jsonrpcnotification) 由客户端发送给服务器，反之亦然，作为单向消息。
接收者 **不得** 发送响应。

```typescript theme={null}
{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
```

* 通知 **不得** 包含 ID。

## 授权

MCP 提供了一个用于 HTTP 的 [授权](/specification/2025-11-25/basic/authorization) 框架。
使用基于 HTTP 的传输的实现 **应该** 符合此规范，
而使用 STDIO 传输的实现 **不应该** 遵循此规范，
而是从环境中检索凭证。

此外，客户端和服务器 **可以** 协商它们自己的自定义认证和
授权策略。

关于进一步讨论和贡献 MCP 认证机制的演进，请加入
[GitHub Discussions](https://github.com/modelcontextprotocol/specification/discussions)
以帮助塑造协议的未来！

## 架构

协议的完整规范定义为
[TypeScript 架构](https://github.com/modelcontextprotocol/specification/blob/main/schema/2025-11-25/schema.ts)。
这是所有协议消息和结构的事实来源。

还有一个
[JSON Schema](https://github.com/modelcontextprotocol/specification/blob/main/schema/2025-11-25/schema.json)，
它是从 TypeScript 事实来源自动生成的，用于
各种自动化工具。

## JSON Schema 使用

模型上下文协议在整个协议中使用 JSON Schema 进行验证。本节阐明了如何在 MCP 消息中使用 JSON Schema。

### 架构方言

MCP 支持带有以下规则的 JSON Schema：

1. **默认方言**：当架构不包含 `$schema` 字段时，默认为 [JSON Schema 2020-12](https://json-schema.org/draft/2020-12/schema)
2. **显式方言**：架构 **可以** 包含 `$schema` 字段以指定不同的方言
3. **支持的方言**：实现 **必须** 至少支持 2020-12，并且 **应该** 记录它们支持哪些附加方言
4. **推荐**：实现者 **推荐** 使用 JSON Schema 2020-12。

### 使用示例

#### 默认方言 (2020-12)：

```json theme={null}
{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "integer", "minimum": 0 }
  },
  "required": ["name"]
}
```

#### 显式方言 (draft-07)：

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

### 实现要求

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

### 架构验证

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

## 通用字段

### `_meta`

`_meta` 属性/参数由 MCP 保留，允许客户端和服务器
在其交互中附加额外的元数据。

某些键名由 MCP 保留用于协议级元数据，如下所述；
实现 **不得** 对这些键处的值做出假设。

此外，[架构](https://github.com/modelcontextprotocol/specification/blob/main/schema/2025-11-25/schema.ts) 中的定义
可以保留特定名称用于特定目的的元数据，如这些定义中所声明的。

**键名格式：** 有效的 `_meta` 键名有两个部分：一个可选的 **前缀** 和一个 **名称**。

**前缀：**

* 如果指定，**必须** 是一系列由点 (`.`) 分隔的标签，后跟斜杠 (`/`)。
  * 标签 **必须** 以字母开头并以字母或数字结尾；内部字符可以是字母、数字或连字符 (`-`)。
  * 实现 **应该** 使用反向 DNS 表示法（例如，`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`

`icons` 属性为服务器提供了一种标准化方式来暴露其资源、工具、提示词和实现的视觉标识。图标通过提供视觉上下文和提高可用功能的可发现性来增强用户界面。

图标表示为 `Icon` 对象的数组，其中每个图标包括：

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

**必需的 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](https://www.w3.org/TR/SVG11/script.html) 或 [扩展功能](https://www.w3.org/TR/SVG11/extend.html) 的 SVG）。
  * 消费者 **可以** 选择禁止特定文件类型或在渲染前清理图标文件。
* 在渲染前验证 MIME 类型和文件内容。将 MIME 类型信息视为建议性的。通过魔术字节检测内容类型；在不匹配或未知类型时拒绝。
  * 维护严格的图像类型白名单。

**用法：**

图标可以附加到：

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

可以提供多个图标以支持不同的显示上下文和分辨率。客户端应根据其 UI 需求选择最合适的图标。