传输

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

​

stdio

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

​

可流式 HTTP

​

安全警告

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

​

向服务器发送消息

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 Bad Request）。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 Method Not Allowed，表明服务器在此端点不提供 SSE 流。
4. 如果服务器启动 SSE 流：
   • 服务器 可以 在流上发送 JSON-RPC 请求 和 通知。这些 请求 和 通知 可以 被 批处理。
   • 这些消息 应该 与任何并发运行的客户端 JSON-RPC 请求 无关。
   • 服务器 不得 在流上发送 JSON-RPC 响应，除非 恢复 与先前客户端请求关联的流。
   • 服务器 可以 随时关闭 SSE 流。
   • 客户端 可以 随时关闭 SSE 流。

​

多个连接

1. 客户端 可以 同时保持连接到多个 SSE 流。
2. 服务器 必须 仅在其中一个连接的流上发送其每条 JSON-RPC 消息；也就是说，它 不得 在多个流上广播相同的消息。
   • 消息丢失的风险 可以 通过使流 可恢复 来减轻。

​

可恢复性和重新交付

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

​

会话管理

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 Bad Request。
3. 服务器 可以 随时终止会话，之后它 必须 对包含该会话 ID 的请求响应 HTTP 404 Not Found。
4. 当客户端收到对包含 Mcp-Session-Id 的请求的 HTTP 404 响应时，它 必须 通过发送新的 InitializeRequest（不带会话 ID）启动新会话。
5. 不再需要特定会话的客户端（例如，因为用户正在离开客户端应用程序） 应该 向 MCP 端点发送带有 Mcp-Session-Id 头的 HTTP DELETE，以显式终止会话。
   • 服务器 可以 对此请求响应 HTTP 405 Method Not Allowed，表明服务器不允许客户端终止会话。

​

序列图

​

向后兼容性

• 继续托管旧传输的 SSE 和 POST 端点，与为可流式 HTTP 传输定义的新”MCP 端点”并存。
  • 也可以合并旧 POST 端点和新 MCP 端点，但这可能会引入不必要的复杂性。

1. 接受用户提供的 MCP 服务器 URL，该 URL 可能指向使用旧传输或新传输的服务器。
2. 尝试向服务器 URL POST 一个 InitializeRequest，带有如上定义的 Accept 头：
   • 如果成功，客户端可以假设这是一个支持新可流式 HTTP 传输的服务器。
   • 如果失败且 HTTP 状态码为 4xx（例如 405 Method Not Allowed 或 404 Not Found）：
     • 向服务器 URL 发出 GET 请求，期望这将打开一个 SSE 流并返回 endpoint 事件作为第一个事件。
     • 当 endpoint 事件到达时，客户端可以假设这是一个运行旧 HTTP+SSE 传输的服务器，并应在所有后续通信中使用该传输。

​

自定义传输