gateway

@mcp-rating/gateway

環境内の API キーを渡さずに MCP サーバーを実行できます。

追加したサーバーが環境変数（AWS_SECRET_ACCESS_KEY、 OPENAI_API_KEY、DATABASE_URL）を読み取れるかどうかは、クライアントの起動方法によって異なります。 公式 MCP SDK は、デフォルトで短い許可リスト（HOME、PATH、USER と いくつかの変数）を渡します。必要なトークンをサーバーに渡すためだけに、環境変数をすべて渡すクライアントやスクリプトもあり、その場合はすべての情報が渡されてしまいます。どの人気クライアントがどの方式を採用しているかはまだ調査していないため、具体名は挙げません。ゲートウェイはクライアント任せにせず、構成した環境変数を使ってすべてのサーバーを起動します。SDK の短い許可リスト（PATH、HOME、USER といくつかの変数）に加え、あなた自身またはマニフェストで指定した変数だけを渡します。環境内のそれ以外の情報は、読み取れません。

ファイルは別の問題です。 デフォルトでは、サーバーは引き続きあなたのユーザー権限で実行されるため、あなたが読み取れるものはサーバーも読み取れます。たとえば、~/.ssh、~/.aws/credentials、プロジェクトの .env です。これを防げるのは、コンテナーによる分離（オプトイン、Docker が必要）のみです。 各レベルで保護される内容をご覧ください。

	環境全体を渡して起動	ゲートウェイ経由
サーバーから見える環境	クライアントが持つすべての情報	短い許可リスト（PATH、HOME、USER といくつかの変数）および指定した変数
環境変数内の認証情報	すべて	指定していないものは渡されません
認証情報ファイル（~/.ssh、~/.aws、.env）	読み取り可能	コンテナー分離が有効でない限り、引き続き読み取り可能

約 10 秒で再現できます。node demo/run-demo.mjs は、偽の認証情報を 2 つ仕込み、サーバーを両方の方法で実行します。仕込んだ値はすべて表示し、環境内に見つかった実際の変数については、値を表示せず変数名だけを表示します。GIF は、実在のマシンの情報を一切含まないクリーンな合成環境から、node demo/render-gif.mjs で生成されています。

これはメタサーバーでもあります。設定に 1 つ追加するだけで、必要に応じて接続できるレジストリー全体を利用できます。事前に読み込む必要はありません。

{ "mcpServers": { "gateway": { "command": "npx", "args": ["-y", "@mcp-rating/gateway"] } } }

コンテキストの消費量が少ない理由

静的に設定した MCP サーバーは、使用するかどうかにかかわらず、毎ターンすべてのツールスキーマをコンテキストに挿入します。ゲートウェイが公開するのは、固定コストのメタツール 13 個です。サーバーのツールは、そのサーバーへの接続後にのみ読み込まれます。

	測定値
実際の MCP サーバーの中央値	2,587 トークン
静的に設定したサーバー 10 個	~25,900 トークン、毎ターン
ゲートウェイのみ	2,644 トークン

サーバー 10 個の場合、常時必要なオーバーヘッドはおよそ 10 分の 1 で、サーバーを追加するほど差は広がります。中央値のサーバー 1 個だけでも、ゲートウェイ全体とほぼ同じコストがかかります。

ただし、常時発生するオーバーヘッドは請求額ではありません — 損益分岐点はこちらです

この10倍という数字は、ウィンドウ内に常時存在するトークン数です。会話にかかるコストではありません。ゲートウェイはターン数も増やすためです。利用する前にサーバーを検出して接続する必要があり、毎ターン会話履歴全体を再送信し、mcp_discover の出力もその後の会話履歴に残ります。

推定値ではなくサーバー独自のトークナイザーを使い、vLLM経由のgemma-4-31Bでエンドツーエンドに測定しました。

	トークン数	ターン数
ゲートウェイ、コールド — サーバーを検出して接続し、ツールを呼び出す	17,904	5
同じツール呼び出し、サーバーの設定済みの場合	6,605	2

サーバーが1つの場合、ゲートウェイのコストは、サーバーを設定するだけの場合の2.7倍です。 すべてのサーバーのスキーマを保持するコストがセットアップのコストを上回るほどサーバーが増えて、初めて節約になります。設定済みサーバー数がN個で、実際に使うのは1つの場合、10ターン作業した後の比較です。

サーバー数	静的設定	ゲートウェイ
1	25,870	70,524	静的設定が2.7倍有利
2	51,740	70,524	静的設定が1.4倍有利
4	103,480	70,524	ゲートウェイが1.5倍有利
10	258,700	70,524	ゲートウェイが3.7倍有利
20	517,400	70,524	ゲートウェイが7.3倍有利

損益分岐点はサーバー3〜5個です。 それ未満なら、手書きの設定のほうが実際に安く、その方法を使うべきです。それを超えるとゲートウェイが有利になり、サーバーを追加するほど差が広がります。ただし、サーバー10個での合計トークン数による正直な数値は約3倍であり、常時発生するオーバーヘッドだけを数えた場合の10倍ではありません。

測定方法について: このプロジェクトが接続して内容を調査した91サーバーのツールスキーマをもとに測定しました。レジストリ内のダウンロード数上位300サーバーから抽出し、各ツールの {name, description, inputSchema} を合計して、クライアントが tools/list から実際に受け取るペイロードを算出し、chars / 4 でサイズを推定しています。これは推定値であり、トークナイザーによる測定ではありません。

平均値ではなく中央値を使う理由は、分布にあります。 平均は9,965トークンですが、長い裾に引き上げられています。91サーバー中19サーバーは10,000トークンを超え、最も大きいものは608個のツールを公開するSpotifyサーバーで、135,666トークンを消費します。これは単体で200kのコンテキストウィンドウの約68％に相当します。平均値を引用すると、ほとんど誰もインストールしないサーバーを使って、このプロジェクトの数値をよく見せることになってしまいます。

節約効果が実際に得られるのは、設定済みのサーバーの大半がほとんどの会話で使われないからです。ただし、自分にも当てはまると考える前に、上記の損益分岐点を確認してください。

chars / 4 による推定値を実際のトークナイザー3種類と比較したところ、実際のトークン数に対してそれぞれ0.88倍、0.98倍、1.01倍でした。そのため、実際より少なく見積もることはありません。

両方を再現できます。スキーマコーパスには node demo/shorts/short2-context.mjs --refresh、エンドツーエンドのコスト計測には demo/ollama-probe.mjs を実行してください —

# gateway cold: must discover and connect first
OLLAMA_HOST=http://host:8000/v1 node demo/ollama-probe.mjs your-model

# baseline: server already attached, like a static config
PRECONNECT=everything-slim OLLAMA_HOST=... node demo/ollama-probe.mjs your-model

仕組み

┌────────────────────┐       ┌──────────────┐       ┌──────────────────┐
│  Claude Desktop /  │ stdio │              │ stdio  │ MCP Server A     │
│  Cursor / Windsurf │◄─────►│  MCP Gateway │◄──────►│ (e.g. filesystem)│
│  (host client)     │       │              │◄──┐    └──────────────────┘
└────────────────────┘       └──────────────┘   │    ┌──────────────────┐
                                    │           └───►│ MCP Server B     │
                                    ▼                │ (e.g. github)    │
                             ┌──────────────┐        └──────────────────┘
                             │ MCP-Rating   │
                             │ Registry API │
                             └──────────────┘

クライアントで各MCPサーバーを手動で設定する代わりに、ゲートウェイは次の処理を行います。

1. MCP-Ratingレジストリを通じてサーバーを検出し、すぐに起動できるサーバーを先に表示します（下記参照）
2. 必要に応じてサーバーに接続します。ローカルサーバーは子プロセスとして起動し、ホスト型サーバーはレジストリに記載されたエンドポイントに接続します
3. 名前空間付きの名前（servername__toolname）を使って、サーバーのツールをプロキシします
4. ツールが追加または削除されたときに、クライアントに通知します

クイックスタート

Claude Desktopの場合

claude_desktop_config.json に追加します。

{
  "mcpServers": {
    "gateway": {
      "command": "npx",
      "args": ["-y", "@mcp-rating/gateway"]
    }
  }
}

次に、Claudeに尋ねます。

• 「データベースで使えるMCPサーバーを検索して」（mcp_discover を使用）
• 「sqliteサーバーに接続して」（mcp_connect を使用）
• 「データベースにクエリを実行して」（プロキシされたツールを直接呼び出す）

Cursor

~/.cursor/mcp.json（またはプロジェクト内の .cursor/mcp.json）：

{
  "mcpServers": {
    "gateway": { "command": "npx", "args": ["-y", "@mcp-rating/gateway"] }
  }
}

Claude Code

claude mcp add gateway -- npx -y @mcp-rating/gateway

Windsurf

~/.codeium/windsurf/mcp_config.json。Cursorと同じ形式です。

{
  "mcpServers": {
    "gateway": { "command": "npx", "args": ["-y", "@mcp-rating/gateway"] }
  }
}

Kiro

Kiro に追加 （Kiro はインストール前に確認します）。または、Cursor と同じ形式で ~/.kiro/settings/mcp.json（ワークスペースでは .kiro/settings/mcp.json）に設定します。

{
  "mcpServers": {
    "gateway": { "command": "npx", "args": ["-y", "@mcp-rating/gateway"] }
  }
}

Kiro が MCP サーバーを実行するのは、サインインしている場合のみです。また、MCP Servers パネルに Enable MCP と表示されている場合は、まずクリックしてください。

Kiro は tools/list_changed を無視します。接続時にゲートウェイのツールリストを一度だけ読み込むため、後から接続したサーバーのツールがエージェントに直接提示されることはありません。エージェントには、mcp_connect が出力する完全な slug__tool 名を使って、mcp_call_tool 経由でツールを呼び出すよう依頼してください。demo/client-probe.mjs を使い、Kiro 1.4.26 で測定しました。

その他の MCP クライアント

{ "command": "npx", "args": ["-y", "@mcp-rating/gateway"] }

設定を編集した後は、クライアントを再起動してください。ほとんどのクライアントは起動時にのみ設定を読み込みます。

mcp_discover で最初に表示されるもの

エージェントが使用できるのは、ゲートウェイが起動できるサーバーのみです。そのため、結果はその基準で並べられ、各グループ内では関連度順に表示されます。

1. 検証済み：レジストリ独自のハーネスで起動し、ツールが一覧表示されました（✓ Started in our test）。
2. 準備完了・未テスト：ここでインストール可能なサーバー、またはヘッダー不要のホスト型エンドポイントで、宣言されているキーが設定済みです。
3. セットアップが必要：宣言されたキーが未設定、ランチャー（uvx、docker）が未インストール、またはゲートウェイからまだ送信できないヘッダーをホスト型エンドポイントが必要としています。
4. テストで起動に失敗：レジストリが試行した際、認証情報なしでは起動しませんでした（✗ Didn't start in our test）。
5. スラッグで起動不可：インストールコマンドもエンドポイントの記録もありません。

「検証済み」とは、起動してツールが一覧表示されたことを意味し、すべてのツールがキーなしで動作することを意味するわけではありません。ハーネスには認証情報が提供されていません。インデックスの大部分はまだ試されておらず、試されていないこと自体は、どちらの意味も持ちません。

メタツール

ゲートウェイには、組み込みツールが13個あります。

ツール	説明
mcp_discover	MCP-Rating レジストリを検索します。ゲートウェイが現在起動できるサーバーが最初に表示されます
mcp_connect	サーバーに接続し、そのツールを利用可能にします
mcp_disconnect	サーバーを切断し、そのツールを削除します
mcp_list_active	接続中のサーバーとそのツールを一覧表示します
mcp_server_info	レジストリまたはライブ接続から、サーバーの詳細情報を取得します
mcp_call_tool	接続中のサーバーのツールを呼び出します
mcp_gateway_health	バージョン、稼働時間、接続状況、レジストリの状態を診断します
mcp_sandbox	サーバーのサンドボックスマニフェスト（環境変数／ネットワーク／ファイルシステム）を表示またはカスタマイズします
mcp_audit	安全性監査ログ。サンドボックス化されたサーバーが実際に行った操作を確認します
mcp_profiles	名前付きの接続プロファイル（仕事用、個人用など）を管理します
mcp_groups	サーバーセットをまとめて接続／切断します
mcp_usage	接続中のサーバーの呼び出し回数、レイテンシ、エラー率を表示します
mcp_recommend	使用状況に基づいてサーバーを推奨します

信頼レベル

接続中の各サーバーには、MCP-Rating の品質スコアに基づいて信頼レベルが付与されます。

• [検証済み] — 高品質で、公式に検証済み
• [信頼済み] — リポジトリがあり、品質が良好で、インストールコマンドまたはリモートエンドポイントがある
• [コミュニティ] — 基本的な品質基準を満たし、レジストリに登録済み
• [未検証] — MCP Rating が把握していないパッケージ。どのレジストリにも登録されていないか、コマンドで起動されたもの

サイトと同様に、安全性スコアがリスク帯にある場合、信頼レベルの上限が設定されます。50未満ではサーバーは最大でも[コミュニティ]、30未満では[未検証]です。

mcp_connect に表示される内容と、確認を求めるタイミング

処理を開始する前に、mcp_connect は、実行対象のパッケージについて MCP Rating が把握している情報を取得します。レジストリのエントリーから取得するか、明示的な command または url の場合はパッケージ自体（npx pkg、uvx pkg、docker run image、エンドポイント）から取得します。コマンドで起動する既知のパッケージは、[Unverified] としてではなく、そのパッケージ自体として評価されます。確認時と接続後に、次の内容が表示されます。

• スコアと信頼レベル、およびサーバーのページ。
• 安全性スコアと各フラグ、その理由。
• MCP Rating 独自の起動テストの結果：起動した、起動しなかった、認証情報が必要、または未テスト。
• 最終リリースと最終コードプッシュ、および各日付の情報源。

[Community] または [Unverified] のサーバーでは確認を求めます。また、信頼レベルにかかわらず、安全性スコアがリスク範囲にある場合、MCP Rating がパッケージを掲載解除している場合、またはレジストリ名が、その名前で MCP Rating が把握しているパッケージとは異なるパッケージを指している場合にも確認を求めます。

最低スコア

MCP_GATEWAY_MIN_SCORE=60（または config.json の "minQualityScore": 60）を設定すると、MCP Rating のスコアが60未満のもの、またはスコアが付けられていないものへの接続を拒否します。スラッグ、レジストリ名、コマンド、URLのいずれを使った場合も同様で、ローカルの node server.js も拒否されます。エージェント自身が設定できるため、confirmed: true ではこの制限は解除されず、設定値を変更する必要があります。レジストリに MCP Rating が含まれている必要があります。0から100までの整数以外を指定すると、黙って「ルールなし」として扱われるのではなく、修正されるまであらゆる接続が拒否されます。

レジストリ

デフォルトでは、ゲートウェイは MCP Rating を検索します。代わりに、または追加で、公式 MCP Registry API（v0.1）に対応する任意のレジストリを検索できます。公式レジストリ、企業独自のレジストリ、または MCP Rating によるそのミラーが対象です。

{
  "mcpServers": {
    "gateway": {
      "command": "npx",
      "args": ["-y", "@mcp-rating/gateway"],
      "env": {
        "MCP_GATEWAY_REGISTRIES": "https://mcprating.io/api/v1,https://registry.acme.internal"
      }
    }
  }
}

• リストはデフォルト設定を置き換えます。 MCP Rating をリストから除くと、ゲートウェイは検出のために MCP Rating にアクセスしなくなります。
• 各エントリーはURLです。 /api/v1 で終わるURLは MCP Rating 独自の API として扱われ、それ以外は MCP Registry API として扱われます。明示的に指定するには、mcprating=URL または mcp-registry=URL と記述します。
• すべてのレジストリを検索し、結果を統合します。 2つのレジストリに掲載されているサーバーは、最初にリストされたレジストリの内容を使って1件だけ表示されます。検索は最大15秒待機します。それまでに応答しなかったレジストリは結果に示され、応答したレジストリの結果は表示されます。
• 名前で接続する場合。 MCP Registry API レジストリのサーバーには、そのレジストリ名で接続します。mcp_connect({slug: "io.github.owner/server"})。以降のセッションでも使用できます。
• スコアの提供元は MCP Rating のみです。 品質スコア、安全性フラグ、起動テストは MCP Rating によるものです。MCP Rating がレジストリの1つに含まれている場合、別のレジストリで見つかったサーバーについても、同じパッケージ、つまり同じ npm または PyPI パッケージ、Docker イメージ、ホスト型エンドポイントに対する MCP Rating の記録を、検索ごとに1回のリクエストで取得します。照合はパッケージ単位で行われ、名前では行われません。どのレジストリでも、任意のパッケージに広く知られた名前を付けられるためです。それ以外の場合、サーバーは unrated かつ [Unverified] として表示され、接続時に確認が求められます。他のレジストリが独自のエントリー（_meta）に記載した数値は読み取りません。誰でも記入できるためです。
• 接続を停止する警告。 MCP Rating が、サーバーのレジストリ名を別のパッケージ名として把握している場合、またはパッケージを掲載解除している場合、mcp_discover はその旨を示し、最後に一覧表示します。この場合、mcp_connect は信頼レベルにかかわらず確認を求めます。
• パートナーキーは MCP Rating にのみ送信されます。 他のレジストリには送信されません。

公式レジストリの検索ではサーバー名のみが照合されます。また、この文書の執筆時点では検索に時間がかかっていました（2026-10-14時点で検索ごとに7～40秒）。ゲートウェイはクエリ内の最長の単語を使って検索し、返された結果を、クエリ内の単語との一致数に基づいて並べ替えます。

設定

ゲートウェイは ~/.mcp-gateway/config.json から設定を読み込みます。

{
  "registryApiUrl": "https://mcprating.io/api/v1",
  "proxyTimeoutMs": 30000,
  "maxConnections": 10,
  "logLevel": "info"
}

環境変数

変数	説明	デフォルト
MCP_GATEWAY_REGISTRY_URL	MCP-Rating API のベース URL	https://mcprating.io/api/v1
MCP_GATEWAY_REGISTRIES	代わりに検索するレジストリ（カンマ区切り）（レジストリを参照）	MCP Rating のみ
MCP_GATEWAY_MIN_SCORE	MCP Rating のスコアがこの値を下回るもの、またはスコアが付いていないものを拒否します（最低スコアを参照）	ルールなし
MCP_GATEWAY_TIMEOUT	プロキシのタイムアウト（ミリ秒）	30000
MCP_GATEWAY_MAX_CONNECTIONS	同時接続の最大数	10
MCP_GATEWAY_LOG_LEVEL	ログレベル（debug/info/warn/error）	info
MCP_GATEWAY_CONTAINER_ISOLATION	L2 コンテナー分離を強制的にオン／オフにします	マニフェストに従う
MCP_GATEWAY_AUDIT_LOG	フォレンジック監査ログのパス	無効
MCP_GATEWAY_PARTNER_KEY	パートナー帰属キー — 広告テレメトリーを有効にします	未設定
MCP_GATEWAY_AD_TRACKING	広告テレメトリーを完全に無効にするには、false に設定します	未設定
MCP_GATEWAY_HTTP_TOKEN	HTTP デーモンモード用のベアラートークン	未設定

セキュリティモデル

このゲートウェイは、サーバーが認識できる内容が、クライアントの起動方法に左右されないようにするためのものです。2 つのレイヤーで制御します。それぞれが何をするのか、また何をしないのかを正確に把握しておくことが重要です。

L1 — 環境のスコープ制限（stdio サーバーでは常に有効）

ダウンストリームサーバーには、MCP SDK のデフォルトの許可リスト（macOS と Linux では HOME、LOGNAME、PATH、SHELL、TERM、USER、Windows では PATH、USERPROFILE、APPDATA、TEMP とその他いくつかの変数）が渡されます。さらに、マニフェストで許可された変数の名前、または接続時に渡した変数の名前のみが渡されます。親環境にあるその他すべての変数（AWS_*、OPENAI_API_KEY、DATABASE_URL など）は渡されません。エクスポートされたシェル関数（BASH_FUNC_*）は転送されず、破棄されます。

これは実際に強制されます。子プロセスは構築された環境で起動されるため、無効化したり回避したりする余地はありません。

L1 はファイルやネットワークを制限しません。 サーバーはユーザーの権限で実行されるため、~/.ssh、~/.aws/credentials、.env ファイルを含め、ユーザーが読み取れるものはすべて読み取ることができ、あらゆるホストに接続できます。マニフェストではネットワークやファイルシステムの制限を宣言できますが、コンテナー外では何も強制されません。接続の概要には、それらは一覧表示されず、「制限なし」と表示されます。

L2 — コンテナー分離（オプトイン）

MCP_GATEWAY_CONTAINER_ISOLATION=true を設定すると、コミュニティ製サーバーと不明なサーバーは、一時コンテナー内で docker／podman を使って実行されます。mcp_sandbox({action: "set", slug: "…", enforcement: "l2-container"}) を使って、個別のサーバーをオプトインすることもできます。コンテナー内のサーバーには、読み取り専用のルートファイルシステム、スクラッチ用の /tmp、およびマニフェストでホストからマウントするよう宣言されたパスのみが提供されます。network: "none" を指定すると、コンテナーのネットワーク接続は完全に遮断されます。Docker または Podman がない場合、ゲートウェイは L1 にフォールバックし、その旨をログに記録します。

ネットワーク許可リスト：利用する前にお読みください

許可リストが適用されるのはL2 の場合のみです。 network: "allowlist" を指定するとフォワードプロキシが起動し、HTTP_PROXY／HTTPS_PROXY を介してコンテナーからそのプロキシに接続します。プロキシは、その接続用に生成されたランダムな認証情報を含むトンネルのみを受け付けます。この認証情報はコンテナーに渡されるこれらの環境変数に含まれます。Docker Desktop では、プロキシはループバックで待ち受けます。Linux 上の Docker では、コンテナーがブリッジ経由で接続するため、すべてのインターフェースで待ち受ける必要があります。他のマシンからの利用を防ぐのは、この認証情報です。

このフィルターが適用されるのは、プロキシに対応したクライアントのみです。 Node の fetch／undici、axios、Python の requests はいずれもこれらの環境変数を使用するため、実際のサーバーの大部分は対象になります。生の TCP ソケットを開くプログラムや、プロキシ環境変数を無視するコンパイル済みバイナリには、フィルターが適用されません。 許可リストは誠実なコードに対する安全策であり、悪意あるコードに対する封じ込め境界ではないと考えてください。そのようなコードへの対策には、network: "none" を使用してください。

サーバーに API キーを渡す

キーはチャットではなく、クライアント設定のゲートウェイの env に設定してください。

{
  "mcpServers": {
    "gateway": {
      "command": "npx",
      "args": ["-y", "@mcp-rating/gateway"],
      "env": { "GITHUB_TOKEN": "ghp_…" }
    }
  }
}

サーバーがキーを受け取るのは、レジストリのエントリーでその変数が宣言されている場合のみです。宣言されていないサーバーでは、値ではなく名前を許可リストに追加してください： mcp_sandbox({action: "set", slug: "…", envAllow: ["GITHUB_TOKEN"]})。

mcp_connect は env: { NAME: "value" } も受け付けます。これは機能しますが、モデルがツール呼び出しにシークレットを書き込む必要があるため、チャットの記録とモデルプロバイダーのログに残ります。

サーバーがモデルに個人データを求める場合

ホスト型サーバーは、通常のツールの結果でメールアドレス、電話番号、カード番号を求めることができ、それに回答するのはモデルです。私たち自身のテスト実行では、ローカルの 31B モデルが「無料枠を記録するため」にメールアドレスを尋ねられ、でっち上げました。これはコンテンツチャネルでのリクエストであるため、サンドボックスでは検出できません。

0.2.6 以降、ゲートウェイは各ツールの結果を調べ、最初の 1,500 文字以内に、個人データを引き渡す動詞と隣接した用語が英語または中国語で含まれているかを確認します。一致した場合、結果とともにモデルが読む警告を追加します。ユーザーに尋ね、値を決してでっち上げないよう伝えます。また、監査記録（mcp_audit）に personal_data_requested も記録します。これはヒューリスティックであり、追加するだけです。サーバーの返信が変更されたり、ブロックされたりすることはありません。

ランタイムが見つからない場合は、代替せずエラーにする

サーバーのランチャー（uvx、docker、python など）がインストールされていない場合、何をインストールすればよいかを示すメッセージとともに接続が失敗します。0.2.4 より前は、ランチャーが見つからないと npx -y <name> に書き換えられ、同じ名前の npm パッケージが実行されていました。Docker のないマシンでは、無関係な npm パッケージの docker が実行されていました。

許可リストのパターンはフェイルクローズです。不正なパターン（ドットが欠けた *example.com など）はすべてに一致するのではなく、何にも一致しません。ゲートウェイは起動時に、意図したとおりに機能しないパターン（*.com のように範囲が広すぎるものを含む）について警告します。

対象外となること

ホストクライアントが SIGKILL で終了された場合、ゲートウェイはシャットダウン処理を実行できず、起動した子プロセスが残ることがあります。SIGINT／SIGTERM は処理され、すべて正常に切断されます。SIGKILL は定義上、捕捉できません。

テレメトリー

有効にしない限りオフです。 広告トラッカーは MCP_GATEWAY_PARTNER_KEY が設定されている場合にのみ作成されます。パートナーキーが設定されていなければ、パートナーのテレメトリーはなく、接続やツール呼び出しに関する情報も送信されません。

パートナーキーが設定されている場合（アトリビューション収益を得ている場合）、接続イベントとツール実行イベントが mcprating.io に送信されます。キーを保持したまま無効にするには、MCP_GATEWAY_AD_TRACKING=false を設定してください。

これとは別に、MCP_GATEWAY_REGISTRIES を設定しない限り、ゲートウェイは mcp_discover、mcp_connect、mcp_recommend のために設定済みのレジストリ（MCP Rating）を呼び出します。これはユーザーが要求した検索であり、バックグラウンドでのレポート送信ではありません。リストに含めた各レジストリには検索内容が見えます。 使用状況の分析データ（mcp_usage）はメモリ内のリングバッファに保存され、プロセスの外に出ることはありません。

開発

npm install
npm run dev        # watch mode
npm run typecheck
npm run build
npm test           # unit tests (env scoping, egress proxy, reconnect, mcp_call_tool)

アーキテクチャ

このゲートウェイは MCP SDK を基盤としており、以下を使用します。

• StdioServerTransport — ホストクライアントと通信します
• StdioClientTransport — 下流サーバーを起動して通信します
• 動的なツール登録 — McpServer.registerTool() + sendToolListChanged()
• ツールの名前空間化 — slug__toolname パターンにより名前の衝突を防ぎます
• Zod スキーマのパススルー — 下流サーバーでの検証を可能にしながら、ホストクライアントの UI 向けにパラメーター名を保持します

ライセンス

MIT — LICENSE を参照してください。

---

これによって見知らぬ人のコードにキーを渡さずに済んだなら、⭐ を付けると、ほかの人にも見つけてもらいやすくなります。