Terminology
本页使用以下术语来描述跨协议版本的互操作：- 现代：将版本、身份和能力作为按请求元数据传递的协议版本（
2026-07-28及之后版本）。 - 旧版：通过
initialize握手建立会话的协议版本（2025-11-25及之前版本）。 - 双时代：同时支持现代和旧版协议版本的实现。
Protocol Version Negotiation
每个请求都会在其_meta 字段中声明正在使用的协议版本。
在 HTTP 上，该版本也会通过
MCP-Protocol-Version 头
携带。
如果服务器未实现请求的版本（无论该版本对服务器未知，还是服务器已知但选择不支持），
它 MUST 以
UnsupportedProtocolVersionError
响应，并列出它支持的版本：
supported 列表中选择双方共同支持的版本并重试请求；如果不存在兼容版本，
则向用户显示错误。
服务器 MUST 实现 server/discover。
客户端 MAY 在发送任何其他请求之前调用它，以预先了解服务器支持的版本，但这并非必需：
客户端可以直接调用任何 RPC，并在其首选版本不受支持时处理 UnsupportedProtocolVersionError。
扩展协商
客户端和服务器可以协商对核心协议之外可选扩展的支持。 扩展通过能力中的extensions 字段声明，该字段是从扩展标识符到各扩展设置对象的映射。
扩展标识符 MUST 遵循 _meta 键命名规则，
并且必须包含前缀。
下面是一个客户端声明
MCP Apps 扩展的示例，该扩展标识为 io.modelcontextprotocol/ui：
io.modelcontextprotocol/tasks 的任务扩展示例：
Backward Compatibility with Initialization-Based Versions
希望同时支持旧版客户端（期望initialize 握手）和现代客户端
（使用按请求元数据）的服务器 MAY 同时实现两种行为。
需要与两类服务器互操作的客户端，会使用绑定页面中指定的、特定于传输的机制来检测服务器所处的时代：
- stdio:
使用
server/discover探测，并在遇到任何非已识别现代错误时回退。 - Streamable HTTP:
尝试现代请求，并在回退之前检查
400 Bad Request的正文。
UnsupportedProtocolVersionError）
都表示服务器是现代服务器：客户端会使用受支持版本重试，而不是回退。其他任何情况都表示服务器是旧版服务器。
时代判定是服务器的属性，而不是单个请求的属性。客户端 SHOULD 在服务器进程（stdio）
或源（HTTP）的生命周期内缓存结果，并且 MAY 在同一服务器配置重启后持久保存该结果；
如果缓存的假设随后失败，则重新探测。
仅支持现代版本的服务器，在任何传输上对 initialize 请求返回错误时，
SHOULD 在错误中列出其支持的协议版本：旧版客户端没有向前升级机制，
这条消息可能是它们唯一能向用户显示的诊断信息。
兼容矩阵
下表总结了客户端和服务器时代的每种组合所预期的结果：
双时代服务器根据客户端的打开方式选择行为：
- 携带现代按请求
_meta的请求会根据本版本以无状态方式服务。 initialize请求选择旧版语义，其作用域按协商出的旧版协议版本规定，限定在 stdio 进程（stdio）或会话（HTTP）内。