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_metaOpenTelemetryicons安全。这些内容看起来比前面的 JSON-RPC 复杂是因为这篇页面并不是普通的 SDK 教程而是 MCP Client 和 Server 都需要遵守的基础通信规范。它主要回答一个 MCP Client 和 MCP Server 想要正确通信双方最少需要遵守哪些共同规则一、整篇页面的阅读地图可以把页面分成六部分章节主要想说明什么MessagesMCP 消息使用什么格式Message PatternsClient 和 Server 可以怎样交互Statelessness一次请求需要携带哪些上下文AuthHTTP 和 STDIO 怎样处理认证信息Schema / JSON Schema怎样描述和检查 JSON 数据结构_meta/icons怎样携带附加信息和 UI 图标整篇文章的主线可以概括为JSON-RPC 规定消息外壳 ↓ MCP 规定交互方式 ↓ JSON Schema 规定数据长什么样 ↓ _meta 携带协议附加信息 ↓ icons 提供可选的 UI 展示信息二、MessagesMCP 使用 JSON-RPC 2.0MCP 没有重新设计一套消息格式而是使用 JSON-RPC 2.0。基础消息分为三类Request Response Notification1. RequestRequest 表示希望对方执行一个操作{jsonrpc:2.0,id:17,method:tools/call,params:{name:get_weather,arguments:{location:Shanghai}}}字段含义字段作用jsonrpc固定为2.0idRequest 的编号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. NotificationNotification 是不需要回复的单向消息{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/read2. Multi Round-Trip Requests有些请求不能立即完成。例如删除数据前需要用户确认。Server 可以先返回{resultType:input_required,inputRequests:[{type:elicitation,message:是否确认删除该项目}]}Client 获得用户答案后再携带答案重试原请求。这种模式简称 MRTR。3. Subscribe and NotifyClient 也可以订阅 Server 的变化通知Client ── 建立订阅 ── Server Client ─ 变化通知 ─── Server Client ─ 变化通知 ─── Server例如 Tool List 发生变化时Server 通知 Client 重新获取。四、Statelessness连接不等于会话MCP2026-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 保存。五、AuthHTTP 和 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]}}它表达了以下规则参数必须是 Objectname必须是 Stringage必须是 Integerage不能小于 0name必填。下面的数据合法{name:Ming,age:25}下面的数据不合法{age:-3}因为它缺少name而且age小于 0。因此JSON Schema 可以理解为JSON 数据的类型说明书和检查规则。八、Schema DialectJSON Schema 也有版本JSON Schema 也有不同版本例如draft-07 2020-12MCP 的规则很简单没有写$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和allOfJSON 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/clientInfoClient 名称和版本io.modelcontextprotocol/clientCapabilitiesClient 支持的能力io.modelcontextprotocol/logLevel希望接收的日志级别io.modelcontextprotocol/subscriptionId标识通知属于哪个订阅traceparent跨服务链路追踪信息在2026-07-28中每个 Request 都必须携带io.modelcontextprotocol/protocolVersion io.modelcontextprotocol/clientCapabilitiesclientInfo和serverInfo主要用于展示、日志和调试不能把它们当成经过验证的用户身份也不能仅凭这些字段授予权限。十三、traceparent是什么一次 Tool Call 可能经过AI Application ↓ MCP Client ↓ MCP Server ↓ Database 或外部 APItraceparent用于告诉这些系统它们正在处理同一次调用。这样在排查性能或错误时就可以把不同服务中的日志和耗时串起来。普通 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 ThemeIcon 主要用于 UI 展示不影响 Tool 的实际执行。Client 处理 Icon 时需要做到最基础的安全检查只允许安全的图片地址下载图片时不要附带用户凭证限制图片大小不要完全相信对方声明的图片类型。如果 Client 没有图形界面可以不支持 Icon。十五、普通 MCP 开发者需要掌握什么如果只是使用 SDK 开发 Tool 或 Server记住下面这些内容就够了MCP Message 使用 JSON-RPC 2.0Request 有idNotification 没有idMCP2026-07-28按无状态方式处理每个 RequestJSON Schema 用来描述 Tool Input 和 Output默认使用 JSON Schema 2020-12本地$ref可以使用远程$ref默认不要自动获取_meta保存协议附加信息不是业务参数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 OverviewMCP 2026-07-28 Schema ReferenceJSON-RPC 2.0 SpecificationJSON Schema 2020-12