MCP Base Protocol 入门：从 JSON-RPC 到 JSON Schema、_meta 与 icons

本文根据 MCP 2026-07-28 Base Protocol Overview 整理。重点是解释这篇规范主要想告诉读者什么，以及 JSON Schema Usage 之后的内容应该怎样理解。

第一次阅读 MCP Base Protocol 页面时，前面的 Request、Response 和 Notification 往往比较容易理解。

到了 JSON Schema Usage，页面突然开始讨论：

• Schema Dialect；
• $ref；
• _meta；
• OpenTelemetry；
• icons 安全。

这些内容看起来比前面的 JSON-RPC 复杂，是因为这篇页面并不是普通的 SDK 教程，而是 MCP Client 和 Server 都需要遵守的基础通信规范。

它主要回答：

一个 MCP Client 和 MCP Server 想要正确通信，双方最少需要遵守哪些共同规则？

一、整篇页面的阅读地图

可以把页面分成六部分：

章节	主要想说明什么
Messages	MCP 消息使用什么格式
Message Patterns	Client 和 Server 可以怎样交互
Statelessness	一次请求需要携带哪些上下文
Auth	HTTP 和 STDIO 怎样处理认证信息
Schema / JSON Schema	怎样描述和检查 JSON 数据结构
_meta / icons	怎样携带附加信息和 UI 图标

整篇文章的主线可以概括为：

JSON-RPC 规定消息外壳
        ↓
MCP 规定交互方式
        ↓
JSON Schema 规定数据长什么样
        ↓
_meta 携带协议附加信息
        ↓
icons 提供可选的 UI 展示信息

二、Messages：MCP 使用 JSON-RPC 2.0

MCP 没有重新设计一套消息格式，而是使用 JSON-RPC 2.0。

基础消息分为三类：

Request
Response
Notification

1. Request

Request 表示希望对方执行一个操作：

{
  "jsonrpc": "2.0",
  "id": 17,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "Shanghai"
    }
  }
}

字段含义：

字段	作用
jsonrpc	固定为 "2.0"
id	Request 的编号
method	要执行的方法
params	方法参数

id 的作用是把后续 Response 和这次 Request 对应起来。

2. Result Response

操作成功时返回 Result：

{
  "jsonrpc": "2.0",
  "id": 17,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "Shanghai: 31°C"
      }
    ]
  }
}

Response 必须使用与 Request 相同的 id。

resultType 常见值包括：

值	含义
complete	请求已经完成
input_required	还需要 Client 补充信息

3. Error Response

操作失败时返回 Error：

{
  "jsonrpc": "2.0",
  "id": 17,
  "error": {
    "code": -32602,
    "message": "Invalid params"
  }
}

其中：

• code 是错误码；
• message 是错误说明；
• data 可以提供更详细的错误信息。

4. Notification

Notification 是不需要回复的单向消息：

{
  "jsonrpc": "2.0",
  "method": "notifications/progress",
  "params": {
    "progress": 50
  }
}

Notification 没有 id，所以接收方不能返回 Response。

三、MCP 的三种交互模式

1. Request and Response

最普通的一问一答：

Client ── Request ──> Server
Client <─ Response ── Server

例如：

tools/list
tools/call
resources/read

2. Multi Round-Trip Requests

有些请求不能立即完成。例如，删除数据前需要用户确认。

Server 可以先返回：

{
  "resultType": "input_required",
  "inputRequests": [
    {
      "type": "elicitation",
      "message": "是否确认删除该项目？"
    }
  ]
}

Client 获得用户答案后，再携带答案重试原请求。这种模式简称 MRTR。

3. Subscribe and Notify

Client 也可以订阅 Server 的变化通知：

Client ── 建立订阅 ──> Server
Client <─ 变化通知 ─── Server
Client <─ 变化通知 ─── Server

例如 Tool List 发生变化时，Server 通知 Client 重新获取。

四、Statelessness：连接不等于会话

MCP 2026-07-28 是无状态协议。

这意味着：

Server 处理当前 Request 时，不能假设它一定记得前一个 Request。

同一条连接可以处理不同任务和不同对话，Connection 或 STDIO Process 本身不代表某个固定 Conversation。

如果业务确实需要跨请求保存状态，应该使用显式 ID：

{
  "taskHandle": "task_20260810_001"
}

后续请求再把这个 ID 传回来：

{
  "name": "get_task_status",
  "arguments": {
    "taskHandle": "task_20260810_001"
  }
}

可以把它理解为：

MCP 协议本身无状态，但业务状态可以通过显式 Handle 保存。

五、Auth：HTTP 和 STDIO 的处理不同

MCP 的 Authorization Framework 主要用于 HTTP Transport。

基本原则是：

• Remote HTTP Server 通常使用 MCP 的 HTTP Authorization 机制；
• Local STDIO Server 通常从环境变量读取凭证；
• STDIO 不需要照搬浏览器 OAuth 跳转流程。

STDIO 的常见关系是：

Host
  ├─ 启动 MCP Server 子进程
  ├─ 注入所需环境变量
  └─ 通过 stdin/stdout 交换 MCP 消息

六、Schema：协议的数据结构定义

官方 MCP Protocol 使用 TypeScript Schema 定义各种消息和结构。

同时，官方还会生成 JSON Schema，供以下工具使用：

• 数据验证；
• 代码生成；
• 编辑器提示；
• 自动化测试。

简单理解：

TypeScript Schema = 官方协议定义
JSON Schema       = 方便各种工具读取和验证的版本

七、JSON Schema 是什么

JSON Schema 用来描述“一份 JSON 应该长什么样”。

例如一个创建用户的 Tool：

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

它表达了以下规则：

• 参数必须是 Object；
• name 必须是 String；
• age 必须是 Integer；
• age 不能小于 0；
• name 必填。

下面的数据合法：

{
  "name": "Ming",
  "age": 25
}

下面的数据不合法：

{
  "age": -3
}

因为它缺少 name，而且 age 小于 0。

因此，JSON Schema 可以理解为：

JSON 数据的类型说明书和检查规则。

八、Schema Dialect：JSON Schema 也有版本

JSON Schema 也有不同版本，例如：

draft-07
2020-12

MCP 的规则很简单：

• 没有写 $schema：默认使用 JSON Schema 2020-12；
• 写了 $schema：按照指定的版本解释；
• MCP Client 和 Server 至少要支持 2020-12。

普通 MCP 开发者优先使用 SDK 生成 Schema 即可。需要自己编写时，使用 2020-12，一般不必专门写 $schema。

九、Schema Validation：检查规则和数据

Schema Validation 包含两件事：

1. Schema 自己是否合法
2. 业务数据是否符合 Schema

例如：

{
  "type": "banana"
}

这不是合法 Schema，因为 banana 不是 JSON Schema 支持的数据类型。

即使参数通过 Schema Validation，也只代表数据结构正确。用户是否存在、余额是否充足、当前用户是否有权限，仍要由业务代码判断。

十、$ref：复用另一段 Schema

$ref 用来引用已经定义过的 Schema。

例如：

{
  "$defs": {
    "Location": {
      "type": "string"
    }
  },
  "type": "object",
  "properties": {
    "city": {
      "$ref": "#/$defs/Location"
    }
  }
}

这里表示 city 使用当前文件中 Location 的定义。

JSON Schema 也允许 $ref 指向一个网络 URL，但 MCP 要求默认不要自动下载网络上的 Schema，因为 URL 可能不安全，也可能造成超时。

初学阶段只需记住：

本地 $ref 可以正常使用；远程 $ref 默认不要自动获取。

十一、oneOf、anyOf 和 allOf

JSON Schema 可以组合多种规则：

Keyword	基础含义
anyOf	满足其中任意一种
oneOf	只满足其中一种
allOf	同时满足全部规则

例如：

{
  "oneOf": [
    {
      "type": "string"
    },
    {
      "type": "integer"
    }
  ]
}

它表示数据可以是 String 或 Integer。

这些规则很灵活，但嵌套太多会让 Schema 难以理解和验证。普通 Tool 参数应尽量保持简单。

十二、_meta：附加的协议信息

_meta 用来携带业务参数之外的协议附加信息。

例如：

{
  "name": "get_weather",
  "arguments": {
    "location": "Shanghai"
  },
  "_meta": {
    "io.modelcontextprotocol/protocolVersion": "2026-07-28",
    "io.modelcontextprotocol/clientCapabilities": {}
  }
}

其中：

arguments = Tool 真正需要的业务参数
_meta     = MCP 通信需要的附加信息

常见 _meta 字段包括：

字段	用途
progressToken	希望接收进度通知
io.modelcontextprotocol/protocolVersion	当前 MCP 版本
io.modelcontextprotocol/clientInfo	Client 名称和版本
io.modelcontextprotocol/clientCapabilities	Client 支持的能力
io.modelcontextprotocol/logLevel	希望接收的日志级别
io.modelcontextprotocol/subscriptionId	标识通知属于哪个订阅
traceparent	跨服务链路追踪信息

在 2026-07-28 中，每个 Request 都必须携带：

io.modelcontextprotocol/protocolVersion
io.modelcontextprotocol/clientCapabilities

clientInfo 和 serverInfo 主要用于展示、日志和调试，不能把它们当成经过验证的用户身份，也不能仅凭这些字段授予权限。

十三、traceparent 是什么

一次 Tool Call 可能经过：

AI Application
    ↓
MCP Client
    ↓
MCP Server
    ↓
Database 或外部 API

traceparent 用于告诉这些系统：它们正在处理同一次调用。

这样在排查性能或错误时，就可以把不同服务中的日志和耗时串起来。

普通 MCP Tool 开发者知道它用于链路追踪即可，不需要自己解析其内部格式。

十四、icons：给 Tool 和 Resource 配图标

MCP Server 可以为 Tool、Prompt、Resource 等对象提供 Icon：

{
  "name": "search",
  "icons": [
    {
      "src": "https://example.com/search.png",
      "mimeType": "image/png",
      "sizes": ["48x48"],
      "theme": "light"
    }
  ]
}

常见字段：

字段	含义
src	图片地址
mimeType	图片类型
sizes	图片尺寸
theme	适合 Light 或 Dark Theme

Icon 主要用于 UI 展示，不影响 Tool 的实际执行。

Client 处理 Icon 时需要做到最基础的安全检查：

• 只允许安全的图片地址；
• 下载图片时不要附带用户凭证；
• 限制图片大小；
• 不要完全相信对方声明的图片类型。

如果 Client 没有图形界面，可以不支持 Icon。

十五、普通 MCP 开发者需要掌握什么

如果只是使用 SDK 开发 Tool 或 Server，记住下面这些内容就够了：

1. MCP Message 使用 JSON-RPC 2.0；
2. Request 有 id，Notification 没有 id；
3. MCP 2026-07-28 按无状态方式处理每个 Request；
4. JSON Schema 用来描述 Tool Input 和 Output；
5. 默认使用 JSON Schema 2020-12；
6. 本地 $ref 可以使用，远程 $ref 默认不要自动获取；
7. _meta 保存协议附加信息，不是业务参数；
8. icons 是可选 UI 信息。

如果使用成熟 MCP SDK，很多底层校验和协议字段都会由 SDK 处理，不需要从头编写 JSON Schema Validator。

十六、总结

MCP Base Protocol 页面真正想说明的是：

不同语言、不同进程中的 MCP Client 和 Server，需要用同样的消息格式、交互方式和数据规则进行通信。

其中：

• JSON-RPC 负责消息格式；
• Message Patterns 负责交互流程；
• Statelessness 负责请求上下文边界；
• JSON Schema 负责描述和验证 JSON 数据；
• _meta 负责携带协议附加信息；
• icons 负责可选的 UI 展示。

对于初学者，理解这些概念各自解决什么问题就足够了。Dialect Validator、远程 $ref 安全策略和 Icon Renderer 等底层实现，可以等真正开发 SDK、Gateway 或复杂 Client 时再深入。

参考资料

• MCP 2026-07-28 Base Protocol Overview
• MCP 2026-07-28 Schema Reference
• JSON-RPC 2.0 Specification
• JSON Schema 2020-12