Transports

Documentation Index

完全なドキュメント索引は modelcontextprotocol.io/llms.txt で取得してください。 さらに調べる前に、このファイルを使って利用可能なすべてのページを見つけてください。

MCP はメッセージの符号化に JSON-RPC を使用します。JSON-RPC メッセージは UTF-8 でエンコードされていなければなりません (MUST)。

このプロトコルは現在、クライアントとサーバー間の通信のために、次の 2 つの標準的なトランスポート機構を定義しています。

1. stdio: 標準入力と標準出力を介した通信
2. Streamable HTTP

クライアントは、可能であれば stdio をサポートするべきです (SHOULD)。

また、クライアントとサーバーは、プラグイン可能な形で custom transports を実装することもできます。

stdio

stdio トランスポートでは、次のように動作します。

• クライアントは MCP サーバーをサブプロセスとして起動します。
• サーバーは標準入力 (stdin) から JSON-RPC メッセージを読み取り、標準出力 (stdout) にメッセージを送信します。
• メッセージは、それぞれ個別の JSON-RPC request、notification、または response です。
• メッセージは改行で区切られ、埋め込み改行を含んではなりません (MUST NOT)。
• サーバーは、情報、デバッグ、エラーの各メッセージを含むあらゆるログ用途のために、UTF-8 文字列を標準エラー出力 (stderr) に書き込んでもかまいません。
• クライアントは、サーバーの stderr 出力を取得しても、転送しても、無視してもかまいません (MAY)。また、stderr 出力がエラー状態を示すと想定するべきではありません (SHOULD NOT)。
• サーバーは、有効な MCP メッセージではないものを stdout に書き込んではなりません (MUST NOT)。
• クライアントは、有効な MCP メッセージではないものをサーバーの stdin に書き込んではなりません (MUST NOT)。

sequenceDiagram participant Client participant Server Process Client->>+Server Process: Launch subprocess loop Message Exchange Client->>Server Process: Write to stdin Server Process->>Client: Write to stdout Server Process--)Client: Optional logs on stderr end Client->>Server Process: Close stdin, terminate subprocess deactivate Server Process

Streamable HTTP

この方式は、プロトコルバージョン 2024-11-05 における HTTP+SSE transport を置き換えるものです。詳細は後述の後方互換性ガイドを参照してください。

Streamable HTTP トランスポートでは、サーバーは複数のクライアント接続を処理できる独立したプロセスとして動作します。このトランスポートは HTTP POST リクエストと GET リクエストを使用します。サーバーは必要に応じて Server-Sent Events (SSE) を利用し、複数のサーバーメッセージをストリーミングできます。これにより、基本的な MCP サーバーだけでなく、ストリーミングやサーバーからクライアントへの notification や request をサポートする、より機能豊富なサーバーも実現できます。

サーバーは、POST メソッドと GET メソッドの両方をサポートする単一の HTTP エンドポイントパス（以下、MCP endpoint と呼びます）を提供しなければなりません (MUST)。たとえば、https://example.com/mcp のような URL がこれに当たります。

Security Warning

Streamable HTTP トランスポートを実装する際は、次の点に注意しなければなりません。

1. サーバーは、DNS リバインディング攻撃を防ぐため、受信するすべての接続で Origin ヘッダーを検証しなければなりません (MUST)。
   • Origin ヘッダーが存在し、かつ不正である場合、サーバーは HTTP 403 Forbidden を返さなければなりません (MUST)。HTTP レスポンス本文には、id を持たない JSON-RPC の error response を含めてもかまいません (MAY)。
2. ローカルで実行する場合、サーバーはすべてのネットワークインターフェイス (0.0.0.0) ではなく、localhost (127.0.0.1) のみにバインドするべきです (SHOULD)。
3. サーバーは、すべての接続に対して適切な認証を実装するべきです (SHOULD)。

これらの保護がなければ、攻撃者は DNS リバインディングを利用して、リモートの Web サイトからローカルの MCP サーバーとやり取りできてしまう可能性があります。

Sending Messages to the Server

クライアントから送られるすべての JSON-RPC メッセージは、新しい HTTP POST リクエストとして MCP endpoint に送信されなければなりません (MUST)。

1. クライアントは、HTTP POST を使って JSON-RPC メッセージを MCP endpoint に送信しなければなりません (MUST)。
2. クライアントは、サポートするコンテンツ型として application/json と text/event-stream の両方を列挙した Accept ヘッダーを含めなければなりません (MUST)。
3. POST リクエストの本文は、単一の JSON-RPC request、notification、または response でなければなりません (MUST)。
4. 入力が JSON-RPC response または notification である場合:
   • サーバーがその入力を受け入れるなら、HTTP ステータスコード 202 Accepted を本文なしで返さなければなりません。
   • サーバーがその入力を受け入れられないなら、HTTP エラーステータスコード（たとえば 400 Bad Request）を返さなければなりません。HTTP レスポンス本文には、id を持たない JSON-RPC の error response を含めてもかまいません。
5. 入力が JSON-RPC request である場合、サーバーは次のいずれかを返さなければなりません。
   • Content-Type: text/event-stream を返して SSE ストリームを開始する
   • Content-Type: application/json を返して 1 つの JSON オブジェクトを返す
     クライアントは、これら両方のケースをサポートしなければなりません。
6. サーバーが SSE ストリームを開始する場合:
   • サーバーは、クライアントが再接続できるよう準備するために、イベント ID と空の data フィールドから成る SSE イベントを直ちに送信するべきです（そのイベント ID を Last-Event-ID として使うため）。
   • サーバーは、イベント ID を持つ SSE イベントをクライアントに送信した後であれば、長時間接続を保持しないようにするため、SSE stream 自体は終了させずに connection をいつでも閉じてもかまいません。その場合クライアントは、再接続を試みることで SSE stream を「ポーリング」するべきです。
   • サーバーが、SSE stream を終了させる前に connection を閉じる場合、閉じる前に標準の retry フィールドを持つ SSE イベントを送信するべきです。クライアントは retry フィールドを尊重し、指定されたミリ秒数だけ待ってから再接続を試みなければなりません。
   • SSE stream には、最終的に POST 本文で送られた JSON-RPC request に対する JSON-RPC response が含まれるべきです。
   • サーバーは、JSON-RPC response を送る前に JSON-RPC request や notification を送ってもかまいません。これらのメッセージは、元のクライアント request に関係するものであるべきです。
   • session の有効期限が切れた場合、サーバーは SSE stream を終了してもかまいません。
   • JSON-RPC response が送信された後、サーバーは SSE stream を終了するべきです。
   • 切断は、ネットワーク状況などにより、いつでも起こりえます。したがって:
     • 切断は、クライアントが request をキャンセルしたこととして解釈するべきではありません。
     • キャンセルするには、クライアントは明示的に MCP の CancelledNotification を送信するべきです。
     • 切断によるメッセージ損失を避けるため、サーバーは stream を resumable にしてもかまいません。

Listening for Messages from the Server

1. クライアントは MCP endpoint に対して HTTP GET を発行してもかまいません。これは、クライアントが先に HTTP POST でデータを送信しなくても、サーバーがクライアントと通信できるように SSE ストリームを開くために利用できます。
2. クライアントは、サポートするコンテンツ型として text/event-stream を列挙した Accept ヘッダーを含めなければなりません。
3. サーバーは、この HTTP GET に対して Content-Type: text/event-stream を返すか、あるいはこの endpoint では SSE ストリームを提供していないことを示す HTTP 405 Method Not Allowed を返さなければなりません。
4. サーバーが SSE ストリームを開始する場合:
   • サーバーは、ストリーム上で JSON-RPC request や notification を送信してもかまいません。
   • それらのメッセージは、クライアントから同時に実行中の JSON-RPC request とは無関係であるべきです。
   • サーバーは、以前のクライアント request に関連するストリームを resuming している場合を除き、ストリーム上で JSON-RPC response を送信してはなりません。
   • サーバーは SSE ストリームをいつでも閉じてもかまいません。
   • サーバーが stream を終了せずに connection を閉じる場合、POST request に対して説明したのと同じポーリング動作に従うべきです。つまり、retry フィールドを送信し、クライアントが再接続できるようにします。
   • クライアントは SSE ストリームをいつでも閉じてもかまいません。

Multiple Connections

1. クライアントは、複数の SSE ストリームに同時に接続したままでいてもかまいません。
2. サーバーは、自身の各 JSON-RPC メッセージを、接続されているストリームのうちただ 1 つにだけ送信しなければなりません。つまり、同じメッセージを複数ストリームにブロードキャストしてはなりません。
   • メッセージ損失のリスクは、stream を resumable にすることで軽減される場合があります。

Resumability and Redelivery

切断された接続の再開と、それがなければ失われるかもしれないメッセージの再配送を支援するために、次のようにします。

1. サーバーは、SSE 標準で説明されているように、SSE イベントに id フィールドを付与してもかまいません。
   • id が存在する場合、その ID は、その session 内のすべてのストリーム全体でグローバルに一意でなければなりません。session 管理を使っていない場合は、その特定のクライアントに関する全ストリーム内で一意でなければなりません。
   • イベント ID は、元のストリームを識別するのに十分な情報をエンコードし、サーバーが Last-Event-ID を正しいストリームに対応付けられるようにするべきです。
2. クライアントが切断後（ネットワーク障害でも、サーバー主導の切断でも）に再開したい場合、MCP endpoint に対して HTTP GET を発行し、最後に受信したイベント ID を示すために Last-Event-ID ヘッダーを含めるべきです。
   • サーバーは、このヘッダーを使って、切断されたそのストリーム上で最後のイベント ID の後に送られていたはずのメッセージを再送し、その地点からストリームを再開してもかまいません。
   • サーバーは、別のストリームで配信されるはずだったメッセージを再送してはなりません。
   • この仕組みは、元のストリームがどのように開始されたか（POST か GET か）にかかわらず適用されます。再開は常に Last-Event-ID を付けた HTTP GET で行います。

言い換えると、これらのイベント ID は、各ストリームごとにサーバーが割り当て、その特定のストリーム内のカーソルとして機能するべきです。

Session Management

MCP の "session" とは、クライアントとサーバーの間で論理的に関連する一連のやり取りであり、initialization phase から始まります。状態を持つ session を確立したいサーバーを支援するため、次のようにします。

1. Streamable HTTP トランスポートを使うサーバーは、初期化時に InitializeResult を含む HTTP response の MCP-Session-Id ヘッダーに session ID を含めることで、session ID を割り当ててもかまいません。
   • session ID は、グローバルに一意であり、かつ暗号学的に安全であるべきです（たとえば、安全に生成された UUID、JWT、あるいは暗号学的ハッシュ）。
   • session ID は、表示可能な ASCII 文字（0x21 から 0x7E まで）だけを含まなければなりません。
   • クライアントは session ID を安全に取り扱わなければなりません。詳しくは Session Hijacking mitigations を参照してください。
2. 初期化時にサーバーから MCP-Session-Id が返された場合、Streamable HTTP トランスポートを使用するクライアントは、その後のすべての HTTP request で MCP-Session-Id ヘッダーにそれを含めなければなりません。
   • session ID を必要とするサーバーは、MCP-Session-Id ヘッダーのない request（初期化を除く）に対して HTTP 400 Bad Request を返すべきです。
3. サーバーは session をいつでも終了してもかまいません。その後、その session ID を含む request に対しては HTTP 404 Not Found を返さなければなりません。
4. クライアントは、MCP-Session-Id を含む request に対する response として HTTP 404 を受け取った場合、新しい InitializeRequest を session ID なしで送って新しい session を開始しなければなりません。
5. クライアントアプリケーションから離れる場合など、特定の session が不要になったクライアントは、その session を明示的に終了するため、MCP-Session-Id ヘッダーを付けた HTTP DELETE を MCP endpoint に送信するべきです。
   • サーバーは、この request に対して HTTP 405 Method Not Allowed を返してもかまいません。これは、クライアントによる session 終了をサーバーが許可していないことを示します。

Sequence Diagram

sequenceDiagram participant Client participant Server note over Client, Server: initialization Client->>+Server: POST InitializeRequest Server->>-Client: InitializeResponse<br>MCP-Session-Id: 1868a90c... Client->>+Server: POST InitializedNotification<br>MCP-Session-Id: 1868a90c... Server->>-Client: 202 Accepted note over Client, Server: client requests Client->>+Server: POST ... request ...<br>MCP-Session-Id: 1868a90c... alt single HTTP response Server->>Client: ... response ... else server opens SSE stream loop while connection remains open Server-)Client: ... SSE messages from server ... end Server-)Client: SSE event: ... response ... end deactivate Server note over Client, Server: client notifications/responses Client->>+Server: POST ... notification/response ...<br>MCP-Session-Id: 1868a90c... Server->>-Client: 202 Accepted note over Client, Server: server requests Client->>+Server: GET<br>MCP-Session-Id: 1868a90c... loop while connection remains open Server-)Client: ... SSE messages from server ... end deactivate Server

Protocol Version Header

HTTP を使用する場合、クライアントは、その後のすべての request に MCP-Protocol-Version: <protocol-version> HTTP ヘッダーを含めなければなりません。これにより、MCP サーバーは MCP プロトコルバージョンに基づいて応答できます。

例: MCP-Protocol-Version: 2025-11-25

クライアントが送るプロトコルバージョンは、initialization 中にネゴシエートされたものであるべきです。

後方互換性のため、サーバーが MCP-Protocol-Version ヘッダーを受け取らず、かつそのバージョンを識別する他の手段もない場合、たとえば初期化時にネゴシエートされたバージョンに依存できない場合には、サーバーはプロトコルバージョン 2025-03-26 を仮定するべきです。

サーバーが無効または未対応の MCP-Protocol-Version を持つ request を受け取った場合、HTTP 400 Bad Request を返さなければなりません。

Backwards Compatibility

クライアントとサーバーは、廃止予定の HTTP+SSE transport（プロトコルバージョン 2024-11-05）との後方互換性を、次のように維持できます。

古いクライアントをサポートしたいサーバー は、次のようにするべきです。

• 新しい Streamable HTTP トランスポート用に定義された "MCP endpoint" と並行して、旧トランスポートの SSE endpoint と POST endpoint の両方を引き続きホストすること。
  • 旧 POST endpoint と新 MCP endpoint を統合することも可能ですが、不必要な複雑さを招く可能性があります。

古いサーバーをサポートしたいクライアント は、次のようにするべきです。

1. ユーザーから MCP サーバー URL を受け取ります。その URL は旧トランスポートを使うサーバーを指している場合も、新トランスポートを使うサーバーを指している場合もあります。
2. 上で定義した Accept ヘッダーを付けて、そのサーバー URL に InitializeRequest を POST してみます。
   • 成功した場合、クライアントはそのサーバーが新しい Streamable HTTP トランスポートをサポートしていると判断できます。
   • HTTP ステータスコード 400 Bad Request、404 Not Found、または 405 Method Not Allowed で失敗した場合:
     • そのサーバー URL に対して GET request を発行し、それによって SSE ストリームが開かれ、最初のイベントとして endpoint イベントが返ることを期待します。
     • endpoint イベントが到着した時点で、クライアントはそのサーバーが旧 HTTP+SSE トランスポートで動作していると判断でき、その後のすべての通信でそのトランスポートを使うべきです。

Custom Transports

クライアントとサーバーは、それぞれの要件に合わせて追加の custom transport 機構を実装してもかまいません。プロトコルはトランスポート非依存であり、双方向のメッセージ交換をサポートする任意の通信チャネル上で実装できます。

custom transports をサポートする実装者は、MCP が定義する JSON-RPC メッセージ形式とライフサイクル要件を維持することを保証しなければなりません。custom transports は、相互運用性を高めるために、その接続確立方法およびメッセージ交換パターンを文書化するべきです。