MCP2HTTP

MCP2HTTP

stdio MCP クライアントをステートレス HTTP MCP サーバーに接続するための、最小限のトランスポートアダプターです。

概要

MCP2HTTP は、stdio トランスポートを使用する Model Context Protocol クライアントが、ステートレス HTTP 経由で MCP サーバーと通信できるようにします。MCP では通常、stdio（ローカルプロセス用）または Server-Sent Events（SSE）トランスポートを使用しますが、このアダプターは通常の HTTP エンドポイントとの橋渡しをし、新たな統合の可能性を広げます。

このアダプターが行うのは基本的なトランスポート層の変換のみですが、クライアントが生成する UUID を Session-Id ヘッダーに含めることで、任意の状態追跡も提供します。プロトコルのセマンティクスを維持し、SSE を必要とせずにクライアントとサーバーが直接やり取りできるため、サーバーレスプラットフォームやレガシーシステムでもシームレスに動作します。

使用方法

MCP クライアントが次の形式の引数でこのコマンドを呼び出すように設定してください。

npx -y mcp2http <endpoint-url> ["Header: Value"...]

たとえば、Claude Desktop の設定ファイル（claude_desktop_config.json）では、次のようにします。

{
  "mcpServers": {
    "my-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "mcp2http",
        "http://localhost:3000/mcp"
      ]
    }
  }
}

引数には、任意の数の HTTP ヘッダーを追加で含めることもできます。たとえば、認証トークンを含める場合は次のようにします。

{
  "mcpServers": {
    "my-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "mcp2http",
        "https://example.com/mcp",
        "Authorization: Bearer token123"
      ]
    }
  }
}

機能する MCP HTTP エンドポイントが必要です。 サーバーの例は近日中に提供される予定です。

機能

クライアント生成セッション追跡

このアダプターは UUID を自動的に生成し、各リクエストに Session-Id ヘッダーとして含めます。 クライアントがセッション ID を生成するのは直感に反するように思えるかもしれませんが、この方式は、HTTP 標準として正式に採用されることのなかった 1996 年の Session-Id 提案に似ています。この仕組みは非常にシンプルで、適切な認証を補完することを目的としています（置き換えるものではありません）。

128 ビットの 16 進数 UUID 形式は、衝突耐性を備え、広く普及した識別子標準を活用しているため、ステートレス HTTP 環境でのリクエストの関連付けに最適です。実装の分断を防ぎ、一貫した動作を確保するため、この設計に準拠するサーバー実装では、128 ビットの 16 進数ではない Session-Id 値（ハイフンの有無を問わず）を拒否する必要があります。

セッション追跡が不要な場合、サーバーは Session-Id ヘッダーを安全に無視できます。 この機能は任意であり、追加の複雑さを伴わずにリクエストを関連付けたい実装向けに、利便性を提供するものです。

機能のフィルタリング

このアダプターは initialize の応答からサーバーの機能を追跡し、サポートされていない機能へのリクエストをブロックします。 この機能は、広告されていない機能を 1 分間に何度も繰り返しポーリングする一部の MCP クライアントの問題に対処します。サーバーが tools など特定の機能のみをサポートしている場合、このアダプターはサーバーにリクエストが届く前にフィルタリングすることで、クライアントがポーリングをひそかに続けていても、不要な負荷を軽減します。

通知の処理

通知（ID のないメッセージ）は暗黙のうちに破棄されます。 この方式は HTTP のリクエスト／レスポンスアーキテクチャに自然に沿うものです。ステートレス HTTP 上で MCP を実装する場合、通知を破棄するのは妥当な選択であり、mcp-golang の HTTP トランスポートなど、ほかの実装も同じ結論に至っています。notifications/initialized については疑問が生じるかもしれませんが、一貫した通知処理による実用上の利点を優先すべきです。それでも、ほかの実装が通知を転送する場合に備え、HTTP MCP サーバーでも通知を適切に処理できるようにしておくとよいでしょう。

ライセンス

MIT