- stdio：通过客户端启动的子进程的标准流传输以换行符分隔的消息。
- Streamable HTTP：每条消息都是发往单个 MCP 端点的 HTTP POST；回复以 JSON 对象或按请求范围的 SSE 流形式到达。
消息
MCP 使用 JSON-RPC 来编码消息。JSON-RPC 消息 MUST 使用 UTF-8 编码。 绑定 MUST 将客户端发送的 requests 和 notifications 传递给 服务器，并将服务器发送的 responses 和 notifications 传递给客户端。不存在其他消息方向：根据 message patterns，服务器不会 发起 JSON-RPC requests，客户端也不会发送 JSON-RPC responses。请求元数据
所有协议元数据都在消息体中传输：每个请求都会携带其 协议版本和客户端能力，位于_meta.io.modelcontextprotocol/*
字段中。
绑定也可以将选定的消息体字段镜像到信封元数据中。Streamable HTTP 传输将它们镜像到
HTTP 标头
中，以便中间代理在不解析消息体的情况下也能路由和检查请求。消息体仍然是事实来源；镜像元数据的绑定会定义如何拒绝不匹配的情况。
取消
每个绑定都定义了客户端如何放弃一个正在进行中的请求：在 stdio 中，客户端发送notifications/cancelled 通知；在 Streamable
HTTP 中，它会关闭该请求的响应流。协议层面的规则在各处都相同；请参见
取消。
自定义传输
客户端和服务器 MAY 实现额外的自定义传输机制，以满足其特定需求。该协议与传输无关，并且可以在任何支持双向消息交换的通信通道上实现。 选择支持自定义传输的实现者 MUST 保留 JSON-RPC 消息格式、消息模式以及按请求的元数据模型。自定义传输 SHOULD 记录其连接建立、消息分帧和取消模式，以帮助互操作性。 在可靠的双向字节流上运行的自定义传输（例如 Unix 域套接字或 TCP）SHOULD 复用 stdio 分帧，而不是定义新的分帧方式：stdio 绑定本质上只是字节流上的以换行符分隔的 JSON-RPC，并且只有其进程生命周期规则是标准流所特有的。向后兼容性
早期的协议修订版本建立了一个连接范围内的会话，并通过initialize 握手进行初始化，还允许服务器发起 JSON-RPC 请求。与这些修订版本互操作的客户端和服务器会检测对端所处的版本时代，并按
版本控制：向后兼容性
中的说明回退，其中包括供实现者参考的兼容性矩阵。每个绑定页面都会描述其特定于传输方式的检测机制。