传输机制

MCP使用JSON-RPC编码消息。JSON-RPC消息必须以UTF-8编码。 该协议目前定义两种客户端-服务器通信的标准传输机制：

1. stdio, 通过标准输入和标准输出进行通信
2. 可流式 HTTP

客户端 应该 在可能的情况下支持 stdio。 客户端和服务器还可以以插件式的方式实现 自定义传输。 standard input/output 在 标准输入输出 传输方式中：

• 客户端将MCP服务器作为子进程启动。
• 服务器从其标准输入（stdin）读取 JSON-RPC 消息，并将消息发送到其标准输出（stdout）。
• 消息是独立的JSON-RPC请求、通知或响应。
• 消息由换行符分隔，并且不得包含嵌入的换行符。
• 服务器可以将UTF-8字符串写入其标准错误输出（stderr）用于日志记录目的。客户端可以捕获、转发或忽略此日志记录。
• 服务器禁止向其 stdout 写入任何无效的 MCP 消息内容。
• 客户端禁止向服务器的stdin写入任何非有效MCP消息的内容。

​

可流式 HTTP

在可流式传输的 HTTP传输中，服务器作为一个独立的进程运行，可以处理多个客户端连接。该传输使用HTTP POST和GET请求。服务器可以选择性地利用Server-Sent Events（SSE）来流式传输多个服务器消息。这使得基本的MCP服务器以及支持流式传输和服务器到客户端通知和请求的更多功能丰富的服务器成为可能。 服务器必须提供单个HTTP端点路径（以下简称MCP端点），同时支持POST和GET方法。例如，这可以是一个类似https://example.com/mcp的URL。

​

安全警告

当实现Streamable HTTP传输时：

1. 服务器 必须 验证所有传入连接的 Origin 头信息，以防止DNS重绑定攻击
2. 当在本地运行时，服务器应该仅绑定到本地主机(127.0.0.1)，而不是所有网络接口(0.0.0.0)
3. 服务器 应当 为所有连接实施适当的身份验证

没有这些保护措施，攻击者可能利用DNS重绑定从远程网站与本地MCP服务器进行交互。

​

向服务器发送消息

从客户端发送的每个 JSON-RPC 消息 必须 是对 MCP 端点进行全新的 HTTP POST 请求。

1. 客户端必须使用 HTTP POST 向 MCP 端点发送 JSON-RPC 消息。
2. 客户端必须包含一个Accept头部，将application/json和 text/event-stream列为支持的内容类型。
3. POST请求的主体必须是一个单独的JSON-RPC请求、通知或响应。
4. 如果输入是JSON-RPC 响应或通知:
   • 如果服务器接受输入，服务器必须返回HTTP状态码202 Accepted且无响应体。
   • 如果服务器无法接受输入，它必须返回一个HTTP错误状态码（例如400错误请求）。HTTP响应体可以包含一个没有id的JSON-RPC错误响应。
5. 如果输入是一个JSON-RPC 请求，服务器必须返回Content-Type: text/event-stream以启动SSE流，或者Content-Type: application/json以返回一个JSON对象。客户端必须同时支持这两种情况。
6. 如果服务器发起 SSE 流：
   • SSE 数据流 应当 最终包含针对 POST 请求体中发送的 JSON-RPC 请求 的 JSON-RPC 响应。
   • 服务器可以在发送JSON-RPC响应之前发送JSON-RPC请求和通知。这些消息应当与原始客户端请求相关。
   • 服务器不应在发送所接收JSON-RPC请求对应的JSON-RPC响应前关闭SSE流，除非会话已过期。
   • 在JSON-RPC 响应发送后，服务器应该关闭SSE流。
   • 断开连接 可以 在任何时候发生（例如，由于网络状况）。 因此：
     • 断开连接不应被理解为客户端取消其请求。
     • 要取消, 客户端 应当 显式地发送一个 MCP CancelledNotification.
     • 为避免因断开连接而导致信息丢失，服务器可以使流可恢复。

​

监听来自服务器的消息

1. 客户端可以向MCP端点发起HTTP GET请求。这可用于打开SSE流，使服务器能够与客户端通信，而无需客户端首先通过HTTP POST发送数据。
2. 客户端 必须 包含一个 Accept 标头，将 text/event-stream 列为受支持的内容类型。
3. 服务器必须在此 HTTP GET 请求的响应中返回 Content-Type: text/event-stream，或者返回 HTTP 405 方法不允许，表示服务器在此端点不提供 SSE 流。
4. 如果服务器发起SSE流：
   • 服务器 可能 通过该流发送 JSON-RPC 请求 和 通知。
   • 这些消息必须与客户端当前运行的任何JSON-RPC请求无关。
   • 服务器 禁止 发送一个 JSON-RPC 响应 在此数据流上，除非 恢复 与前一个客户端请求相关联的数据流。
   • 服务器可能随时关闭SSE流。
   • 客户端可以随时关闭SSE流。

​

多路连接

1. 客户端可以同时保持连接到多个SSE流。
2. 服务器 必须 仅在一条已连接的数据流上发送其每一条 JSON-RPC 消息；也就是说，它 严禁 在不同数据流间广播同一条消息。
   • 通过让数据流具备可恢复性，或许能 缓解消息丢失的风险。

​

可恢复性与重新交付

为了支持恢复中断的连接，并重新发送可能丢失的消息：

1. 服务器可以为自己的SSE事件附加一个id字段，正如SSE标准中所述.
   • 如果存在此ID，它必须在该session的所有流中全局唯一——或者，如果未使用会话管理，则针对该特定客户端的所有流全局唯一。
2. 如果客户端希望在连接中断后恢复，它应该向MCP端点发出HTTP GET请求，并包含 Last-Event-ID 标头以指示其接收到的最后事件ID。
   • 服务器可以使用此标头来重放在最后一个事件ID之后在断开的流上应发送的消息，并从该点恢复流。
   • 服务器严禁重播本应在不同流上传递的消息。

换句话说，这些事件ID应该由服务器以每流为基础进行分配，作为特定流内的游标。

​

会话管理

一个MCP“会话”包括了客户端与服务器之间逻辑上相关的交互，从初始化阶段开始。为了支持想要建立有状态会话的服务器：

1. 使用可流式传输HTTP传输的服务器可以在初始化时分配会话ID，通过将其包含在承载InitializeResult的HTTP响应的Mcp-Session-Id头中。
   • 会话ID 应该是全局唯一且加密安全的（例如：安全生成的UUID、JWT或加密哈希）。
   • 会话ID 必须只包含可见的ASCII字符（范围从0x21到0x7E）。
2. 如果服务器在初始化期间返回了Mcp-Session-Id，使用可流式HTTP传输的客户端必须将其包含在后续所有HTTP请求的Mcp-Session-Id标头中。
   • 需要会话ID的服务器应该对不包含Mcp-Session-Id标头的请求（除初始化外）返回HTTP 400错误请求响应。
3. 服务器可以随时终止会话，之后它必须对包含该会话ID的请求响应HTTP 404 Not Found。
4. 当客户端收到包含Mcp-Session-Id的请求返回HTTP 404响应时，它必须通过发送不带会话ID的新InitializeRequest来启动新会话。
5. 不再需要特定会话的客户端（例如，因为用户将离开客户端应用程序）应该向 MCP 端点发送带有 Mcp-Session-Id 标头的 HTTP DELETE 请求，以明确终止会话。
   • 服务器可以响应此请求并使用 HTTP 405 Method Not Allowed，表示服务器不允许客户端终止会话。

​

序列图

​

协议版本头部

如果使用 HTTP 协议，客户端必须在所有向 MCP 服务器的后续请求中包含 MCP-Protocol-Version: HTTP 标头，以便 MCP 服务器能够根据 MCP 协议版本进行响应。 例如：MCP-Protocol-Version: 2025-06-18 客户端发送的协议版本应该是初始化过程中协商的版本。 为向后兼容，如果服务器没有接收到MCP-Protocol-Version 头部，且没有其他方式识别版本——例如依赖于 初始化期间协商的协议版本——服务器应当假定协议 版本为2025-03-26。 如果服务器收到包含无效或不支持的 MCP-Protocol-Version 的请求, 它 必须 以 400 Bad Request 响应.

​

向后兼容性

客户端和服务器可以通过以下方式保持与已弃用的 HTTP+SSE 传输协议（来自协议版本2024-11-05）的向后兼容性： 服务器想要支持老旧客户端，应当：

• 继续同时托管旧传输服务的SSE和POST端点，以及为可流式HTTP传输定义的新"MCP端点"。
  • 同样可以将旧的POST端点与新的MCP端点结合使用，但这可能会引入不必要的复杂性。

客户端 若希望支持旧版服务器，应：

1. 从用户处接收一个MCP服务器URL，该URL可能指向使用旧传输协议或新传输协议的服务器。
2. 尝试向服务器URL POST一个InitializeRequest，包含如上定义的Accept头部信息:
   • 如果成功，客户端可以认为这是一个支持新可流式 HTTP 传输的服务器。
   • 如果失败且出现HTTP 4xx状态码（例如，405 方法不允许或404 未找到）:
     • 向服务器URL发出GET请求，预计这将打开一个SSE流 并返回一个endpoint事件作为首个事件。
     • 当 endpoint 事件到达时，客户端可以假设这是一个运行旧版HTTP+SSE传输的服务器，并且应使用该传输进行所有后续通信。

​

自定义传输方式

Clients and servers 可以 实现额外的自定义传输机制以适应其特定需求。该协议与传输无关，可以在支持双向消息交换的任何通信通道上实现。 选择支持自定义传输的实现者必须确保保留由MCP定义的JSON-RPC消息格式和生命周期要求。自定义传输应该记录其特定的连接建立和消息交换模式以促进互操作性。