协议版本: 2025-06-18
MCP使用JSON-RPC编码消息。JSON-RPC消息必须以UTF-8编码。 该协议目前定义两种客户端-服务器通信的标准传输机制：
  1. stdio, 通过标准输入和标准输出进行通信
  2. 可流式 HTTP
客户端 应当 尽可能支持标准输入输出。 客户端和服务器还可以以插件式的方式实现 自定义传输。

​
标准输入输出

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

​
可流式HTTP

这取代了协议版本2024-11-05中的HTTP+SSE 传输。请参阅下面的向后兼容性 指南。
在可流式传输的HTTP传输中，服务器作为独立进程运行，能够处理多个客户端连接。该传输使用HTTP POST和GET请求。服务器可选择性地利用 服务器发送事件（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列为支持的 content types。
  3. POST请求的主体必须是单个JSON-RPC 请求、通知或响应。
  4. 如果输入是JSON-RPC 响应或通知:
    • 如果服务器接受输入，服务器必须返回HTTP状态码202 Accepted且无响应体。
    • 如果服务端无法接收输入，它必须返回一个HTTP错误状态码（例如，400 错误请求）。HTTP响应体可以包含一个JSON-RPC错误响应，该响应不含id。
  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. 服务器必须要么返回Content-Type: text/event-stream作为对此HTTP GET的响应，或者返回HTTP 405方法不被允许，表明服务器在此端点不提供SSE流。
  4. 如果服务器发起了SSE流：
    • 服务器可以通过流发送JSON-RPC 请求和通知。
    • 这些消息应该与客户端同时运行的任何JSON-RPC 请求不相关。
    • 服务器不允许在流上发送JSON-RPC 响应，除非是在 恢复与先前客户端请求相关联的流的情况下。
    • 服务器可以在任何时候关闭SSE流。
    • 客户端可以随时关闭SSE流。

​
多连接

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

​
可恢复性与重投递

为了支持恢复中断的连接，并重新发送可能丢失的消息：
  1. 服务器 可以附加一个id字段到它们的SSE事件，如同在 SSE标准中描述的那样。
    • 如果该字段存在，此ID必须在指定会话内的所有流中全局唯一——或者，若未采用会话管理，则在特定客户端的全部流中保持唯一性。
  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 Bad Request响应。
  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端点结合使用，但 这可能会引入不必要的复杂性。
Clients 若需支持旧版服务器，应当：
  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传输的服务器，并在所有后续通信中都使用这种传输方式。

​
自定义传输方案

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