MCP

MCP Gateway 導入前ガイド：複数の MCP サーバーと REST API を固定ツールサーフェスへ集約（非商用ライセンス）

複数の MCP サーバーと REST API のツール定義でコンテキストが埋まるケースに最適です。単一の Rust バイナリがすべてのバックエンドを 14〜16 個の固定メタツールに集約し、gateway_search_tools で検索、gateway_invoke で呼び出します。利用前で最も重要な前提は、既定のライセンスが個人と非商用利用のみを対象とし、商用運用には商用ライセンスが必要なことです。

公式ソース · GitHub - MikkoParkkola/mcp-gateway

インストール

brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run

複数の MCP サーバーや REST API を 1 つの AI クライアントに接続すると、ツール定義そのものがコンテキストを圧迫し始めます。MCP Gateway のアプローチは、クライアントとすべてのツールの間に単一の Rust バイナリを置くことです。さまざまなバックエンドがその背後に接続され、エージェントに見えるのは各バックエンドの完全な定義ではなく、14〜16 個のツールからなるコンパクトなメタサーフェスです。コンテキスト内のツール定義が増えるほど、本来のタスクに回せる予算は減ります。それを固定の小さなサーフェスへ収束させることこそ、このツールが解決しようとしている問題です。手を動かす前に前提を 1 つ確認してください。既定では非商用ライセンスで提供され、個人および非商用利用（ゲートウェイ全体の実行を含む）は無料、商用での運用には商用ライセンスが必要です。

向いている人

  • すでに複数の MCP サーバーと REST API を接続している、または接続を計画していて、ツールリストの大きさを安定させたいユーザーに向いています。後ろにいくつバックエンドを繋いでも、エージェントが向き合うのは固定の小さなメタツール群であって、すべてのバックエンド定義の合計ではありません。
  • 自分のマシン上で常駐サービスを 1 つ動かし続けられる人に向いています。ゲートウェイはローカルの HTTP サービスとして動作し、クライアントはローカルエンドポイント経由で接続します。
  • 商用環境でのそのままの利用には向きません。商用運用には商用ライセンスが必要で、これは導入前に解決しておくべき前提です。汎用的な構成要素からなる小さな MIT コアだけが MIT ライセンスで公開されています。
  • バックエンドが少なく、ツールリストがもともと短い場合は、集約の価値は限定的です。小規模なケースでの具体的な利得について、根拠となる比較データは示されていません。
  • 対応クライアントの一覧、リモートデプロイ、認証方式については根拠が示されておらず、未確認の項目です。自分で勝手に仮定しないでください。

3 分で最初の一回を終える

  • 前提：Homebrew を使える環境。公式のインストール導線は Homebrew tap で、それ以外のインストール方法は根拠にありません。
  • 公式のメインパスにある 3 つのコマンドを順に実行します：
brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run
  • 2 ステップ目の setup wizard は、既存のサーバーを取り込み、クライアントを接続します。ここで注意したいのは、これがローカル状態への書き込みだという点です。ゲートウェイとクライアントのローカル設定を書き換える、読み取り専用ではない操作であり、どのファイルに何をどう保存するかは、根拠には項目ごとの説明がありません。
  • 3 ステップ目を起動すると、ゲートウェイはローカル HTTP サービスとして動きます。クライアント側は公式が示す設定スニペットに従って接続します。スニペットは gateway という名前のサーバーを http 型として宣言し、ローカルの 39400 番ポート上の /mcp パスを指します：
{
  "mcpServers": {
    "gateway": {
      "type": "http",
      "url": "http://localhost:39400/mcp"
    }
  }
}
  • 成功の合図：クライアントが http://localhost:39400/mcp に接続できたら、ツールリストは固定の小さなセットに収束します。ここで gateway_search_tools を 1 回呼んでください。公式の説明では、バックエンドのツールを検索するためのものです。接続済みのバックエンドのツールが検索結果に返ってくれば、クライアントからゲートウェイへの経路は通っています。このツールに readOnlyHint の表示があるかは根拠に示されておらず、読み取り専用かどうかは未確認です。最初の一回は検索にとどめ、書き込み系のアクションは実行しないでください。この時点でエージェントが読み込んでいるのは、すべてのバックエンド定義ではなく、固定の小さなメタツール群です。

使用例

  • ケース 1：複数サーバーのツールスタックをスリム化する。状況：クライアントに複数の MCP サーバーが接続済みで、各バックエンドのツール定義がコンテキストを消費している。やり方：既存のサーバーをウィザードに取り込ませ、クライアント側には http://localhost:39400/mcp の 1 エンドポイントだけを残します。期待できること：エージェントのツールサーフェスは 14〜16 個程度に固定され、すべてのバックエンド定義の合計ではなくなります。特定の機能が必要になったら、まず gateway_search_tools で検索して位置づけます。判断基準：クライアントに表示されるツール数が、接続したバックエンドのツール総数より明確に少ないかどうか。
  • ケース 2：検索してから実際のツールを 1 回呼ぶ。状況：接続済みのバックエンド（MCP サーバーまたは REST API）が提供する機能を実行したい。やり方：まず gateway_search_tools で対象ツールを特定し、次に gateway_invoke で呼び出します。公式が説明する使い方はまさにこの 2 つのメタツール、検索と呼び出しです。期待できること：呼び出しは対応するバックエンドへ転送され、その結果が返ります。具体的な出力は接続したバックエンド次第で、根拠の中に固定のサンプル出力はありません。期待したツールが見つからない場合は、そのバックエンドをウィザードで取り込み済みかを先に確認し、検索をやり直してください。

利用の境界

  • ライセンスと制約：個人と非商用利用は無料で、ゲートウェイ全体の実行も含まれます。商用運用には商用ライセンスが必要で、汎用的な構成要素からなる小さな MIT コアのみが MIT で公開されています。この項目が使えるか・どの範囲で使えるかを決めるので、すべての判断の前に置いてください。
  • 読み書きの性質と副作用：ゲートウェイ自体はローカル常駐サービスです。ウィザードはローカル設定を書き込み、gateway_invoke はバックエンドのツールを実際に駆動します。副作用は呼び出したバックエンド次第なので、実行前に対象操作の性質と確認ポイントを確認してください。
  • 依存関係：インストールは Homebrew に依存します。既存サーバーの接続はウィザードの取り込みで行います。
  • 未確認の項目：対応クライアントの一覧、REST API を接続するための具体的な設定形式、localhost 以外へのデプロイ、認証方式、そして各メタツールが readOnlyHint を持つかどうかは、いずれも根拠に記載がありません。ゲートウェイ自身のアクセス制御の有無やログの記録方法も同様に記載がありません。説明が見つからないことはリスクがないことを意味しません。導入前は公式リポジトリの現在のドキュメントを正としてください。