概述

本页定义传输层为承载 MCP 消息必须提供的能力、标准传输绑定，以及定义新绑定的要求。

协议语义在每种传输上都是相同的。传输是一种绑定：它定义消息如何分帧与投递、请求元数据如何承载，以及取消与终止如何发出信号。它不定义消息的含义：消息模式属于核心协议的一部分，在每种绑定上都相同。各绑定页面规定了标准传输：

客户端和服务端也可以实现自定义传输。

消息

MCP 使用 JSON-RPC 对消息进行编码。JSON-RPC 消息 MUST（必须）采用 UTF-8 编码。

绑定 MUST（必须）将客户端发送的请求和通知投递给服务端，并将服务端发送的响应和通知投递给客户端。不存在其他消息方向：根据消息模式，服务端不发起 JSON-RPC 请求，客户端也不发送 JSON-RPC 响应。

所有协议元数据都在消息体中传递：每个请求都在 _meta.io.modelcontextprotocol/* 字段中携带其协议版本和客户端能力。

绑定 MAY（可以）额外将选定的消息体字段镜像到信封元数据中。Streamable HTTP 传输将它们镜像到 HTTP 头中，以便中间层无需解析消息体即可路由和检查请求。消息体仍是唯一事实来源；镜像元数据的绑定需定义如何拒绝不匹配的情况。

每种绑定都定义客户端如何放弃一个进行中的请求：在 stdio 上，客户端发送 notifications/cancelled 通知；在 Streamable HTTP 上，客户端关闭该请求的响应流。协议层面的规则在任何地方都相同；参见取消。

客户端和服务端 MAY（可以）实现额外的自定义传输机制，以满足其特定需求。协议与传输无关，可以在任何支持双向消息交换的通信通道上实现。

选择支持自定义传输的实现者 MUST（必须）保留 JSON-RPC 消息格式、消息模式以及逐请求元数据模型。自定义传输 SHOULD（应该）记录其连接建立、消息分帧和取消模式，以促进互操作性。

运行在可靠双向字节流（例如 Unix 域套接字或 TCP）之上的自定义传输 SHOULD（应该）复用 stdio 分帧，而不是定义新的分帧：stdio 绑定只是在字节流之上以换行分隔的 JSON-RPC，只有其进程生命周期规则是标准流特有的。

更早的协议修订版建立了带 initialize 握手的连接作用域会话，并允许服务端发起 JSON-RPC 请求。与这些修订版互操作的客户端和服务端会检测对端的时代并回退，如版本管理：向后兼容所述，其中包含面向实现者的兼容性矩阵。每个绑定页面都描述其传输特有的检测机制。