Supergateway

Supergateway を使うと、MCP stdio ベースのサーバーを SSE（Server-Sent Events） または WebSockets（WS） 経由で、1 つのコマンドで実行できます。これは、リモートアクセスやデバッグ、または MCP サーバーが stdio のみをサポートしている場合にクライアントへ接続する際に便利です。

質問やアイデアがある方、または気軽に話したい方は、Discord のコミュニティにご参加ください。

サポート：

• Supercov — コーディングエージェントとソフトウェアファクトリー向けのカバレッジ 🌙
• Superinterface
• Supercorp

インストールと使い方

npx 経由で Supergateway を実行します：

npx -y supergateway --stdio "uvx mcp-server-git"

• --stdio "command"：stdio 経由で MCP サーバーを実行するコマンド
• --sse "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app"：接続先の SSE URL（SSE→stdio モード）
• --streamableHttp "https://mcp-server.example.com/mcp"：接続先の Streamable HTTP URL（StreamableHttp→stdio モード）
• --outputTransport stdio | sse | ws | streamableHttp：出力する MCP トランスポート（デフォルト：--stdio の場合は sse、--sse または --streamableHttp の場合は stdio）。--sse または --streamableHttp で指定したリモートサーバーは、sse、ws または streamableHttp 経由でも提供できます。リモートサーバー → SSE、WS、または Streamable HTTPを参照してください
• --port 8000：リッスンするポート（stdio→SSE、stdio→WS、または stdio→Streamable HTTP モード、デフォルト：8000）
• --host 127.0.0.1：リッスンするアドレス。例：127.0.0.1 または ::1（[::1] も使用できます）（stdio→SSE、stdio→WS、または stdio→Streamable HTTP モード、デフォルト：すべてのインターフェース）。バインド先は --baseUrl では制御されません。接続を受け付けるアドレスを制限するのは --host のみです。SSE→stdio および Streamable HTTP→stdio モードでは、何もリッスンしないため使用できません
• --baseUrl "http://localhost:8000"：SSE クライアント用のベース URL（stdio→SSE モード、任意）
• --ssePath "/sse"：SSE サブスクリプション用のパス（stdio→SSE モード、デフォルト：/sse）
• --messagePath "/message"：メッセージ用のパス（stdio→SSE または stdio→WS モード、デフォルト：/message）
• --streamableHttpPath "/mcp"：Streamable HTTP 用のパス（stdio→Streamable HTTP モード、デフォルト：/mcp）
• --stateful：stdio→Streamable HTTP をステートフルモードで実行します
• --sessionTimeout 60000：セッションのタイムアウト時間（ミリ秒）（ステートフルな stdio→Streamable HTTP モードのみ）
• --protocolVersion "2025-06-18"：ゲートウェイがサーバーを自ら初期化する際に、クライアントのリクエストでプロトコルバージョンが指定されていない場合に使用するバージョン（ステートレスな stdio→Streamable HTTP モード、デフォルト：2024-11-05）
• --header "x-user-id: 123"：ヘッダーを1つ以上追加します（stdio→SSE、stdio→Streamable HTTP、SSE→stdio、または Streamable HTTP→stdio モード。複数回指定できます）。ローカルサーバーの場合はゲートウェイの応答に付加され、リモートサーバー（--sse、--streamableHttp）の場合はリモートサーバーに送信されます
• --oauth2Bearer "some-access-token"：指定した Bearer トークンを含む Authorization ヘッダーを追加します
• --logLevel debug | info | none：ログレベルを制御します（デフォルト：info）。より詳細なログには debug を、すべてのログを抑制するには none を使用します。
• --logFormat text | json：ログ行の形式（デフォルト：text）。json を指定すると、ELK などのログパイプライン向けに、time、level、msg と、ログ呼び出しに値が含まれる場合は data を含む JSON オブジェクトを1行ずつ出力します。ログは text と同じストリームに出力されるため、stdio の出力には引き続き MCP メッセージのみが含まれます。
• --cors：CORS を有効にします（stdio→SSE または stdio→WS モード）。すべてのオリジンを許可するには値を指定せずに --cors を使用し、許可するオリジンを1つ以上指定することもできます（例：正規表現で照合する場合は --cors "http://example.com" または --cors "/example\\.com$/"）。
• --healthEndpoint /healthz："ok" を返すエンドポイントを1つ以上登録します（stdio 出力以外のすべてのモード。複数回指定できます）
• --healthCheck gateway | server：ヘルスエンドポイントが確認する対象（デフォルト：gateway）。gateway はゲートウェイが稼働中であれば "ok" を返します。server は MCP サーバーも確認します。サーバーを起動するか（--sse／--streamableHttp の場合はリモートサーバーとのセッションを開き）、初期化して ping を送り、停止します。サーバーが10秒以内に応答した場合は "ok" を返し、それ以外の場合は理由とともに 503 を返します（例：unhealthy: the server exited (code=1, signal=null)）。応答は10秒間再利用されるため、1秒ごとにポーリングしても、サーバーが起動するのは10秒あたり最大1回です。起動時のログには、ヘルス状態が悪化したときと回復したときが記録されます
• --toolPrefix "github_"：サーバーが一覧表示するすべてのツール名の前に付けます。たとえば、search は github_search になります（すべてのモード）。クライアントはその名前でツールを呼び出し、サーバーには元の名前が渡されます。指定した文字列がそのまま使われるため、区切り文字も含めてください。ツール名には英字、数字、_、-、. を使用でき、最大128文字です。プレフィックスまたは名前がこの条件を満たさない場合、ゲートウェイが警告します
• --tools search --tools get_issue：これらのツールのみを、サーバー独自の名前で公開します（すべてのモード）。それ以外のツールは tools/list から除外され、呼び出しもサーバーに到達する前に -32602 Unknown tool で拒否されます。これは、サーバーが存在しないツールを拒否するのと同じです。引数なしの --tools を指定すると、ツールは公開されません
• --apiKey "some-key"：クライアントに、Authorization: Bearer <key> または X-API-Key: <key> としてこのキーを提示するよう要求します（stdio→SSE、stdio→WS、または stdio→Streamable HTTP モード。複数回指定できます）。SUPERGATEWAY_API_KEY=some-key も使用できます。API キーの必須化を参照してください
• --apiKeyFile /run/secrets/keys：このファイルに1行につき1つ記載されたキーを受け付けます（空行は無視されます）。SUPERGATEWAY_API_KEY_FILE=/run/secrets/keys も使用できます
• --exitWithProcess <pid>：プロセス <pid> が終了したときに MCP サーバーを停止して終了します（すべてのモード）。起動元の PID（例：$$）を渡してください。直接の親プロセスでなくてもよいため、npx 経由でも機能します。約1秒ごとに確認します。stdin パイプを使って Supergateway を起動する起動元では、この指定は不要です。4.0 以降、Supergateway は stdin が閉じると終了します。
• --config servers.json：サーバーフラグの代わりに、設定ファイルからサーバーと設定を読み込みます。設定ファイルから複数のサーバーを指定するを参照してください
• --checkConfig：--config と併用して、ファイルを確認し、各サーバーのパスと出力を一覧表示して終了します
• --printConfig：解決済みの設定を出力して終了します。キー、Bearer トークン、すべての env の値、すべての URL のクエリ、および機密情報を含む名前のヘッダーは置き換えられます。コマンドライン（args、stdio）は記述されたまま出力されるため、共有する前に内容を確認してください。--config を指定しない場合は、指定したコマンドラインと同等の設定ファイルを出力します

stdio → SSE

MCP stdio サーバーを SSE サーバーとして公開します。

npx -y supergateway \
    --stdio "npx -y @modelcontextprotocol/server-filesystem ./my-folder" \
    --port 8000 --baseUrl http://localhost:8000 \
    --ssePath /sse --messagePath /message

• イベントの購読：GET http://localhost:8000/sse
• メッセージの送信：POST http://localhost:8000/message
• 各 SSE 接続で、それぞれ独自のサーバープロセスが起動します。

SSE → stdio

リモート SSE サーバーに接続し、ローカルでは stdio 経由で公開します。

npx -y supergateway --sse "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app"

リモート SSE MCP サーバーをローカルのコマンドライン環境に統合する場合に便利です。

リクエスト送信時にヘッダーを渡すこともできます。これは認証に便利です。

npx -y supergateway \
    --sse "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app" \
    --oauth2Bearer "some-access-token" \
    --header "X-My-Header: another-header-value"

Streamable HTTP → stdio

リモート Streamable HTTP サーバーに接続し、ローカルでは stdio 経由で公開します。

npx -y supergateway --streamableHttp "https://mcp-server.example.com/mcp"

このモードは、新しい Streamable HTTP トランスポートプロトコルを使用する MCP サーバーへの接続に便利です。SSE モードと同様に、認証用のヘッダーも渡せます。

npx -y supergateway \
    --streamableHttp "https://mcp-server.example.com/mcp" \
    --oauth2Bearer "some-access-token" \
    --header "X-My-Header: another-header-value"

stdio → Streamable HTTP

MCP stdio サーバーを Streamable HTTP サーバーとして公開します。

クライアントと stdio サーバーが共通のプロトコルバージョンをサポートしている場合、レガシー MCP と 2026-07-28 をサポートします。自動ネゴシエーションに対応するクライアントは、サーバーが要求した場合にレガシーへフォールバックできます。

--stateful はレガシーセッションを維持します。MCP 2026-07-28 は独立したリクエストを使用し、トランスポートセッションを作成しません。

対話型の MCP 2026-07-28 操作は、複数のリクエストにわたって継続できます。継続と明示的な再試行は、非アクティブ状態が最大 5 分続くまで利用でき、保存される継続状態は最大 64 個です。この上限に達すると、古い状態はより早く期限切れになる場合があります。

ステートレスモード

npx -y supergateway \
    --stdio "npx -y @modelcontextprotocol/server-filesystem ./my-folder" \
    --outputTransport streamableHttp \
    --port 8000

ステートフルモード

npx -y supergateway \
    --stdio "npx -y @modelcontextprotocol/server-filesystem ./my-folder" \
    --outputTransport streamableHttp --stateful \
    --sessionTimeout 60000 --port 8000

Streamable HTTP エンドポイントのデフォルトは http://localhost:8000/mcp です（--streamableHttpPath で設定可能）。

stdio → WS

MCP stdio サーバーを WebSocket サーバーとして公開します。

npx -y supergateway \
    --stdio "npx -y @modelcontextprotocol/server-filesystem ./my-folder" \
    --port 8000 --outputTransport ws --messagePath /message

• WebSocket エンドポイント：ws://localhost:8000/message
• 各 WebSocket 接続で、それぞれ独自のサーバープロセスが起動します。

リモートサーバー → SSE、WS、または Streamable HTTP

別のトランスポートを必要とするクライアント向けにリモート MCP サーバーを提供するか、独自の API キーの背後で提供します。

npx -y supergateway \
    --streamableHttp "https://mcp.example.com/mcp" \
    --oauth2Bearer "$UPSTREAM_TOKEN" \
    --outputTransport streamableHttp --stateful --apiKey "$MCP_API_KEY"

• 各クライアントセッションでは、リモートサーバーとのセッションが個別に作成されます。セッションはクライアント側で終了したとき、またはシャットダウン時に終了します。
• --header と --oauth2Bearer はリモートサーバーに送信されます。クライアント独自の Authorization と API キーは送信されません。
• リモートサーバーからクライアントへのリクエスト（サンプリング、ルート、エリシテーション）は中継されます。
• リモートサーバーが停止している、クライアントを拒否する、または接続が切断された場合、そのセッションだけが失敗します。
• 2026-07-28 プロトコルのステートレスリクエストは、そのバージョンに対応するリモート Streamable HTTP サーバーへ中継されます。ゲートウェイは 1 分ごとに（server/discover）を問い合わせます。これに対応しないサーバーと、すべてのリモート SSE サーバーには、従来どおり接続します。クライアントにはそのバージョンがサポートされていないことが通知され、ネゴシエーションを行うクライアントは以前のバージョンにフォールバックします。

API キーの必須化

デフォルトでは、ポートに接続できる人は誰でもサーバーを利用できます。--apiKey を指定すると、stdio→SSE、stdio→WS、または stdio→Streamable HTTP へのすべてのリクエストにキーが必要になります。

npx -y supergateway \
    --stdio "npx -y @modelcontextprotocol/server-filesystem ./my-folder" \
    --outputTransport streamableHttp --apiKey "$MCP_API_KEY"

curl -H "Authorization: Bearer $MCP_API_KEY" ...   # or: -H "X-API-Key: $MCP_API_KEY"

• 有効なキーのないリクエストには 401 Unauthorized が返されます。--healthEndpoint のパスと、--cors を指定した場合のブラウザーのプリフライトリクエストは引き続き利用できます。
• --apiKey、--apiKeyFile、SUPERGATEWAY_API_KEY、SUPERGATEWAY_API_KEY_FILE で指定したキーはすべて同時に受け付けられます。そのため、古いキーを削除する前に新しいキーを追加して、キーをローテーションできます。
• キーが空の場合、キーのファイルを読み取れない場合、またはファイルにキーが含まれていない場合、認証なしで実行するのではなく、ゲートウェイの起動時に停止します。
• キーがログに記録されることはありません。キーが平文で送信されないよう、HTTPS（リバースプロキシの背後など）を使用してください。
• SSE→stdio または Streamable HTTP→stdio からリモートサーバーにキーを送信するには、--header または --oauth2Bearer を使用してください。これらの構成では --apiKey は拒否されます。

設定ファイルから複数のサーバーを起動する

--config は、Claude Desktop などの MCP クライアントが使用する mcpServers ファイルを読み込むため、クライアントのファイルをそのまま使用できます。各サーバーは、1つのポート上の /<name> で提供されます。

{
  "port": 8000,
  "mcpServers": {
    "git": { "command": "uvx", "args": ["mcp-server-git"] },
    "files": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./my-folder"],
      "outputTransport": "streamableHttp",
      "apiKey": "${FILES_KEY}",
    },
  },
}

npx -y supergateway --config servers.json

• git は http://localhost:8000/git/sse と /git/message で SSE 経由で提供され、files は http://localhost:8000/files/mcp で Streamable HTTP 経由で提供されます。
• サーバーは、command + args（クライアントと同じく、シェルを介さずに実行）、stdio（--stdio と同様のシェルコマンドライン）、または url + type（sse または http）で指定します。env と cwd で環境とディレクトリを設定します。
• 上記のすべてのオプションは、フラグ名（outputTransport、stateful、cors、headers、apiKey、healthEndpoint、toolPrefix、tools など）を使ってサーバーごとに設定できます。トップレベルで設定すると、すべてのサーバーのデフォルトになります。デフォルトはコマンドラインの場合と同じです。ローカルサーバーは SSE 経由で、url サーバーは stdio 経由で提供されます。
• path を使うと、/<name> 以外の場所でサーバーを提供できます。URL の一部として使えない名前には path が必要です。あるサーバーの URL が別のサーバー、またはゲートウェイ自身の healthEndpoint から応答される場合、ゲートウェイは起動を拒否します。
• port、host、logLevel、logFormat、exitWithProcess とトップレベルの healthEndpoint は、ゲートウェイ自体の設定です。トップレベルの healthEndpoint はゲートウェイ全体に応答し、サーバーに設定した場合はそのサーバーのパス配下で応答します。"healthCheck": "server" を指定すると、サーバー固有のヘルスエンドポイントはそのサーバーをチェックします。ゲートウェイが稼働している間、ゲートウェイのヘルスエンドポイントは "ok" のままなので、1つのサーバーに障害が起きてもゲートウェイ全体の障害にはなりません。
• サーバーに設定した apiKey はそのサーバーだけを保護し、トップレベルの apiKey を置き換えます。空のリストは拒否されます。1つのサーバーをキーなしにするには、トップレベルではなく、キーが必要なサーバーに apiKey を設定します。--apiKey、--apiKeyFile、または SUPERGATEWAY_API_KEY のキーは、すべてのサーバーを保護します。
• "disabled": true を指定すると、そのサーバーはスキップされます。クライアント専用のキー（autoApprove、timeout、disabledTools など）は警告され、無視されます。それ以外の不明なキーは、最も近い既知のキーを提示するエラーになります。
• ${VAR}、${VAR:-default}、${env:VAR} は、stdio のコマンドラインを除くすべての値で、環境変数に置き換えられます。stdio のコマンドラインはシェル自身が展開します。設定されていない変数があるとエラーになります。$$ はリテラルの $ です。
• --config と併用できるフラグは、ゲートウェイ自体のもの（--port、--host、--logLevel、--logFormat、--exitWithProcess、--healthEndpoint、--apiKey、--apiKeyFile）です。これらはファイルの設定より優先され、起動ログにその旨が表示されます。--stateful などのサーバー用フラグは、どのサーバーを指すのか不明になるため拒否されます。
• 複数のサーバーがある場合、サーバーに関する各ログ行の先頭にサーバー名（[git]）が付き、JSON ログには server フィールドが含まれます。
• Windows では、"command": "npx" は他のクライアントと同様に動作します。npx.cmd のようなスクリプト形式のコマンドは cmd.exe 経由で実行され、各引数は記述されたとおりにサーバーへ渡されます。stdio はシェル経由で実行されます。
• コメントと末尾のカンマを使用できます（JSONC）。編集後に --checkConfig を実行してください。

url サーバーは、stdio 以外の出力を使用する場合、ローカルサーバーと同様に提供されます（リモートサーバー → SSE、WS、または Streamable HTTP を参照）。たとえば、"outputTransport": "streamableHttp" を指定します。

ポート上のサーバーと並行して、1つの url サーバーで stdio 出力を使用できます。これは、Claude Desktop など、設定ファイルを使って Supergateway を起動するクライアント向けです。クライアントはそのサーバーと stdin および stdout で通信し、他のクライアントは残りのサーバーに HTTP 経由でアクセスします。この場合、すべてのログは stderr に出力されます。プロセスは起動したクライアントに属します。stdin が閉じられた場合、シグナルを受信した場合、または stdio サーバーが停止した場合（たとえば、リモートサーバーが最初の接続を拒否した場合）、すべてのサーバーが停止し、終了コードは stdio サーバーのものになります。

1 つの URL でサーバーを組み合わせる

独自の mcpServers を持つエントリーは、エントリーの URL でそれらを 1 つの MCP サーバーとして提供します。

{
  "port": 8000,
  "outputTransport": "streamableHttp",
  "mcpServers": {
    "dev": {
      "mcpServers": {
        "git": { "command": "uvx", "args": ["mcp-server-git"] },
        "files": {
          "command": "npx",
          "args": ["-y", "@modelcontextprotocol/server-filesystem", "."],
        },
        "docs": {
          "url": "https://docs.example.com/mcp",
          "type": "http",
          "toolPrefix": "docs_",
        },
      },
    },
  },
}

http://localhost:8000/dev/mcp のクライアントには、3 つすべてのツール、プロンプト、リソースが表示されます。

• 名前は変更されません。 リクエストは、指定されたツール、プロンプト、またはリソースを持つサーバーに送られます。2 つのサーバーが同じ名前を提供する場合は、最初に記載されたサーバーが優先され、もう一方は非表示になります。その旨はログに一度だけ記録されます。両方を残すにはサーバーに toolPrefix を設定し、表示するサーバーのツールを選ぶには tools を設定します。1 つの URL の背後にツールが多すぎると、モデルが選びにくくなります。関連するものを組み合わせてください。
• 各セッションにはそれぞれ独自のサーバーがあり、 クライアントの初期化時に起動します。起動できないサーバーは除外され、その旨がログに記録されます。どのサーバーも起動できない場合に限り、セッションは失敗します。サーバーが後から停止した場合、そのサーバーが担当していた呼び出しは失敗し、クライアントにはリストが変更されたことが通知されます。ほかのサーバーは引き続き動作します。
• サーバーからクライアントへのリクエスト（サンプリング、ルート、エリシテーション）は、1 つのサーバーの場合と同様に、それらをサポートする出力（SSE、WebSocket、ステートフルな Streamable HTTP）で動作します。
• プロトコルバージョンは、すべてのサーバーが応答するバージョンのうち最も古いものです。ケイパビリティは、いずれかのサーバーが持つものすべてです。それぞれの instructions は、サーバー名の下にまとめられます。
• リストは 1 ページで返され、 記載された順に各サーバーの項目が並びます。
• URL の設定（outputTransport、apiKey、cors、healthEndpoint、...）はエントリーに指定します。組み合わせたサーバーには、command／args／env／cwd、stdio、または url／type／headers／oauth2Bearer と、toolPrefix／tools を指定できます。組み合わせは 1 階層までです。
• stdio（"outputTransport": "stdio"）では、組み合わせたエントリーをデスクトップクライアントが起動することで、独自の設定エントリー 1 つから複数のサーバーにアクセスできます。単一のリモートサーバーと同様に、ポート上のサーバーと並行して実行できます。
• 2026-07-28 は、組み合わせたすべてのサーバーがこのバージョンをサポートする場合に応答します（ゲートウェイは 1 分に 1 回、各サーバーに確認します）。この場合、各リクエストでは対象のサーバーだけが起動し、server/discover とリストのリクエストはすべてのサーバーに送られます。いずれかのサーバーがこのバージョンをサポートしない場合、エントリーは以前のバージョンで応答し、バージョンをネゴシエートするクライアントはフォールバックします。
• 未対応： タスク。組み合わせたサーバーは同じモデルコンテキストを共有するため、互いの結果を信頼できるサーバーだけを組み合わせてください。

Node なしで使う：スタンドアロン実行ファイル

各リリースには、Node を内蔵した Supergateway の単一実行ファイルも含まれているため、Node がインストールされていない環境でも実行できます。使用できるフラグは同じです。

Homebrew（macOS および Linux）：

brew install supercorp-ai/tap/supergateway

macOS（Apple Silicon）および Linux：ダウンロードして展開します。必要に応じて、darwin-arm64 の代わりに linux-x64、linux-arm64、linux-musl-x64、または linux-musl-arm64 を使用してください。

curl -fsSL https://github.com/supercorp-ai/supergateway/releases/latest/download/supergateway-darwin-arm64.tar.gz | tar -xz

./supergateway --stdio "uvx mcp-server-time" --port 8000

Windows（PowerShell）：

Invoke-WebRequest https://github.com/supercorp-ai/supergateway/releases/latest/download/supergateway-win-x64.zip -OutFile supergateway.zip; Expand-Archive supergateway.zip .

.\supergateway.exe --stdio "uvx mcp-server-time" --port 8000

知っておくとよいこと：

• ラップする MCP サーバー自体には、引き続き独自のランタイムが必要です。--stdio "npx -y ..." には Node が、--stdio "uvx ..." には uv が必要です。
• Linux では glibc 2.28 以降が必要です。Alpine では linux-musl ビルドを使用し、先に apk add libstdc++ を実行してください。
• Intel Mac 向けのスタンドアロンビルドはありません。brew install を実行すると、Homebrew の Node 上で npm パッケージがインストールされます。
• 実行ファイルは、有料の証明書でコード署名されていません。ブラウザーからダウンロードした場合、初回実行時に macOS Gatekeeper と Windows SmartScreen の確認が表示されます。curl、PowerShell、Homebrew によるインストールには影響しません。
• 各アーカイブはリリースの SHA256SUMS に記載されています。また、gh attestation verify supergateway-darwin-arm64.tar.gz -R supercorp-ai/supergateway を実行すると、このリポジトリの CI でビルドされたことを確認できます。

シャットダウン

正常にシャットダウンするには、5 秒以上の時間を確保してください。Ctrl-C でゲートウェイを停止したときに、子サーバーが SIGTERM を処理できるようにしてください。

ネットワーク出力を使うゲートウェイは、stdin に接続されたパイプを閉じても停止します。stdin を無視するか、/dev/null からリダイレクトして起動すると、実行を継続します。

MCP Inspector を使用する例（stdio → SSE モード）

1. Supergateway を実行する：

npx -y supergateway --port 8000 \
    --stdio "npx -y @modelcontextprotocol/server-filesystem /Users/MyName/Desktop"

2. MCP Inspector を使用する：

npx @modelcontextprotocol/inspector

これで、Supergateway 経由でツールやリソースを一覧表示したり、MCP アクションを実行したりできます。

ngrok での使用

ngrok を使用して、ローカルの MCP サーバーを公開して共有します。

npx -y supergateway --port 8000 --stdio "npx -y @modelcontextprotocol/server-filesystem ."

# In another terminal:
ngrok http 8000

ngrok はリモートアクセス用の公開 URL を提供します。

MCP サーバーには、次のような URL でアクセスできます：https://1234-567-890-12-456.ngrok-free.app/sse

Docker での実行

Docker ベースのワークフローを使用すると、ローカルでの Node.js のセットアップが不要になります。すぐに実行できる Docker イメージはこちらから利用できます： supercorp/supergateway。GHCR でも利用できます：ghcr.io/supercorp-ai/supergateway

公式イメージの使用

docker run -it --rm -p 8000:8000 supercorp/supergateway \
    --stdio "npx -y @modelcontextprotocol/server-filesystem /" \
    --port 8000

Docker がイメージを自動的にプルします。MCP サーバーはコンテナーのルートディレクトリ（/）で実行されます。必要に応じて、ホストのディレクトリをマウントできます。

依存関係を含むイメージ

必要に応じて、以下の依存関係を含む Supergateway のビルド済みイメージをプルしてください。

• uvx Supergateway と uv/uvx が含まれているため、uvx を直接呼び出せます：

  docker run -it --rm -p 8000:8000 supercorp/supergateway:uvx \
    --stdio "uvx mcp-server-fetch"
  

• deno Supergateway と Deno が含まれており、Deno ベースの MCP サーバーをすぐに実行できます：

  docker run -it --rm -p 8000:8000 supercorp/supergateway:deno \
    --stdio "deno run -A jsr:@omedia/mcp-server-drupal --drupal-url https://your-drupal-server.com"
  

イメージを自分でビルドする

このチェックアウトからビルドします：

npm ci
npm run pack:release
docker build -f docker/base.Dockerfile -t supergateway \
  --build-arg VERSION="$(node -p "require('./.release/manifest.json').version")" \
  --build-arg PACKAGE_SHA256="$(node -p "require('./.release/manifest.json').sha256")" .

docker run -it --rm -p 8000:8000 supergateway --stdio "npx -y @modelcontextprotocol/server-filesystem ."

Claude Desktop での使用（SSE → stdio モード）

Claude Desktop では、Supergateway の SSE→stdio モードを使用できます。

NPX ベースの MCP サーバーの例

{
  "mcpServers": {
    "supermachineExampleNpx": {
      "command": "npx",
      "args": [
        "-y",
        "supergateway",
        "--sse",
        "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app"
      ]
    }
  }
}

Docker ベースの MCP サーバーの例

{
  "mcpServers": {
    "supermachineExampleDocker": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "supercorp/supergateway",
        "--sse",
        "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app"
      ]
    }
  }
}

Cursor での使用（SSE → stdio モード）

Cursor でも、SSE→stdio モードで Supergateway と連携できます。設定は Claude Desktop と同様です。

Cursor 向け NPX ベースの MCP サーバーの例

{
  "mcpServers": {
    "cursorExampleNpx": {
      "command": "npx",
      "args": [
        "-y",
        "supergateway",
        "--sse",
        "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app"
      ]
    }
  }
}

Cursor 向け Docker ベースの MCP サーバーの例

{
  "mcpServers": {
    "cursorExampleDocker": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "supercorp/supergateway",
        "--sse",
        "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app"
      ]
    }
  }
}

注： --header フラグを使ったヘッダーの送信には対応していますが、Authorization ヘッダー（通常はスペースを含みます。例："Bearer 123"）を渡す必要がある場合は、コマンドライン引数のスペースに関する既知の Cursor のバグがあるため、--oauth2Bearer フラグを使用する必要があります。

トラブルシューティング

--baseUrl のホストが使用されない

stdio→SSE モードでは、--baseUrl のパスのみがクライアントに渡されます。--baseUrl https://mcp.example.com/gateway を指定すると、メッセージエンドポイントは /gateway/message となり、クライアントは接続に使用したホストに POST します。Copilot Studio など、絶対エンドポイント URL を必要とするクライアントでは、--outputTransport streamableHttp を使用してください。

MCP を使用する理由

Model Context Protocol は、AI ツールとのやり取りを標準化します。Supergateway は MCP の stdio サーバーを SSE または WS サービスに変換し、ウェブベースまたはリモートのクライアントとの連携やデバッグを簡素化します。

追加リソース

• Superargs - 実行時に MCP サーバーへ引数を渡します。

コントリビューター

• @cesar-blog
• @twinity1
• @wandergis
• @remidebette
• @raja-anbazhagan
• @plutonji
• @madrover
• @1235467
• @medram
• @wunsir
• @joshmouch
• @akularefiner
• @Cipppp
• @alibek-sumup
• @davibaldin
• @Sodawyx
• @brrock
• @jwalitptl
• @jakajancar
• @thedadams
• @iutx
• @hxy91819
• @gamedevsam
• @davidferlay
• @bossanyit
• @bbracha-evinced
• @homer6
• @aleleba
• @bimax
• @essentialols
• @gcoinstash-cmd
• @nullStack65
• @srijan
• @TheItschi
• @wowsofine
• @yanziwei
• @tttcoding666
• @aneasystone
• @luyunfeng-bytedance
• @kvick-games
• @nowireless4u
• @paul-maas
• @ArnaudBger
• @alvaroalon2
• @oshaban
• @springbrookconsultingllc-byte
• @jstar0
• @v8eta
• @zaggash
• @0xt3ch
• @werebear73
• @move-hoon
• @dustindoan
• @swarthyplacebo
• @ildunari
• @tamermina
• @frankstupak
• @brainoir
• @JuliaF1988
• @terjefl
• @yangzinan
• @ckhsponge
• @AxelFooley
• @Growdy
• @sulivanti
• @EvanSchalton
• @suneetagarwalre-boop
• @edmcman
• @noyoa
• @JamesSlocumIH
• @mike12806
• @oscar-izval
• @haissamtariqzaman
• @rubenmajor2
• @quigles1977
• @jmcgurk2
• @maxx3250
• @julioccorderoc
• @logan-crosby
• @BishopMartin
• @gkinter
• @JoeLuker
• @agerit-programator2
• @sfasching
• @RussellZager
• @Farzy
• @body-cmd
• @cosmic-fire-eng
• @0xbrainkid
• @dangdinhquan
• @iandol
• @micci184
• @manmao
• @sibelius
• @NathanNeves
• @Avi-Robusta
• @yakovyarmo
• @GhimBoon
• @akirilyuk
• @ongeluk
• @dparkmit24
• @glani
• @enxilium
• @scalabreseGD
• @davidjitca
• @sbatista-uc
• @terafin
• @ecdesigns2007
• @brendandebeasi
• @waldman
• @O7Furkan17
• @HalmSascha
• @Paul-Kyle
• @janosborst
• @MartinZvelebil
• @longfin
• @griffinqiu
• @folkvir
• @wizizm
• @dtinth
• @rajivml
• @NicoBonaminio
• @sibbl
• @podarok
• @jmn8718
• @TraceIvan
• @zhoufei0622
• @ezyang
• @aleksadvaisly
• @wuzhuoquan
• @mantrakp04
• @mheubi
• @mjmendo
• @CyanMystery
• @earonesty
• @StefanBurscher
• @tarasyarema
• @pcnfernando
• @Areo-Joe
• @Joffref
• @michaeljguarino
• @qdrddr
• @Shellishack
• @anyuan95

コントリビューション

Issue やプルリクエストを歓迎します。CONTRIBUTING.mdをご覧ください。サポートが必要な場合はDiscordでお尋ねください（SUPPORT.md）。セキュリティ上の問題は非公開でご報告ください（SECURITY.md）。アクセシビリティについてはACCESSIBILITY.mdをご覧ください。

テスト

Supergateway は Node Test Runner でテストされています。

ローカルでテストスイートを実行するには、Node 24+ が必要です。nvmを使うと、次のコマンドでインストールして有効化できます。

nvm install 24
nvm use 24
npm install
npm run build
npm test

tests/helpers/mock-mcp-server.jsスクリプトはローカル MCP サーバーを提供するため、 すべてのテストをネットワークに接続せずに実行できます。

ほかに、このビルドと直近のリリースを比較するチェックが2つあり、リリースを取得するためにネットワーク接続が必要です。CI では、すべてのプルリクエストで両方のチェックを実行します。

npm run test:versions   # the same client against the release and this build, side by side
npm run test:released   # the release's own end-to-end tests, run against this build

意図した差分は、その理由とともにtests/crossVersion.intended.tsまたはtests/releasedTests.intended.jsonに記録します。それ以外の差分がある場合は失敗します。

ライセンス

MIT License