4q-tokenz

Name: 4q-tokenz
Author: steveweltman

ローカル

github.com/steveweltmanAI・エージェント21 週間前に更新

リポジトリ

4q-tokenz について

4q-tokenzは、LLMと複数のMCPサーバーの間に置き、全ツール一覧をクライアントに公開せず、必要に応じて検索・呼び出しを行うプロキシゲートウェイです。エージェントごとのレーンで上流サービスやツールを分離し、利用状況と接続状態のメトリクスも提供します。

主な機能

01検索・呼び出し・スキーマのツールを公開
02ツールを必要に応じて検出・読み込み
03BM25検索によるツール検索
04エージェントレーンごとのアクセス分離
05Prometheusメトリクスの提供

活用シーン

01ツール一覧に使うコンテキストを削減
02複数のMCPサーバーからツールを検索・実行
03エージェントごとに利用可能なサーバーを制限

MCP 対応

stdioまたはHTTPで上流のMCPサーバーに接続し、クライアントにツール検索、呼び出し、詳細確認のインターフェースを提供します。エージェントごとのレーンにより、検出・実行できるツールを制限できます。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定

{
  "mcpServers": {
    "steveweltman-4q-tokenz": {
      "command": "npx",
      "args": [
        "-y",
        "4q-tokenz"
      ]
    }
  }
}

起動コマンドnpx -y 4q-tokenz

ローカルサーバーにはマシン上の実行環境（Node.js 18 以上など）が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ

npm4q-tokenz1.15.0stdio

ツール

ツール一覧はまだ取得されていません

ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。

詳細

MCP プロキシゲートウェイ

LLM に全カタログではなく 3 つのツール（mcp_search、mcp_call、mcp_schema）だけを公開し、トークン使用量を削減する、コンテキストを考慮した MCP プロキシです。

これが必要な理由

複数の MCP サーバーを LLM に接続すると、各サーバーのすべてのツールが LLM のコンテキストウィンドウに一覧表示されます。複数の MCP サーバーにまたがって 50〜100 個のツールがある一般的なワークスペースでは、リクエストのたびにスキーマの説明だけで数千トークンを消費します。

MCP プロキシゲートウェイは LLM と MCP サーバーの間に位置し、次の機能を提供します。

JIT ツール読み込み — 上流サーバーのツールは起動時に一度だけ検出され、その後は必要に応じて呼び出されます。クライアントに全カタログが表示されることはありません。
インテリジェント検索 — クエリに適したツールを見つけるための高速な語彙検索（BM25）を提供します。ツールトークンは起動時に事前計算されるため、クエリごとのスコアリングにオーバーヘッドはありません。
トークンの節約 — LLM に表示されるのは 50 個以上ではなく、3 つのツールスキーマ（検索、呼び出し、スキーマ）のみです。ツールを多用するワークフローでは、1 ターンあたり通常 20〜40％削減できます。
ネイティブ依存関係ゼロ — 純粋な JavaScript で実装されており、ネイティブモジュール、モデルのダウンロード、ML パッケージによるサプライチェーンリスクはありません。

┌─────────────────────────────────────────────────────────────────┐
│                         Your LLM                                │
│   (sees only: mcp_search, mcp_call, mcp_schema)                │
└────────────────────┬────────────────────────────────────────────┘
                     │
         ┌───────────▼──────────────┐
         │   MCP Proxy Gateway      │
         │ ┌──────────────────────┐ │
         │ │ Tool Registry        │ │
         │ │ (BM25 lexical)       │ │
         │ └──────────────────────┘ │
         │ ┌──────────────────────┐ │
         │ │ Connector Manager    │ │
         │ │ (Idle timeout reap)  │ │
         │ └──────────────────────┘ │
         └────────────┬─────────────┘
                      │
        ┌─────────────┼─────────────┐
        │             │             │
        ▼             ▼             ▼
   ┌─────────┐  ┌─────────┐  ┌─────────┐
   │Google   │  │MailerLite│ │Your Svc │
   │Gmail    │  │ Campaigns│ │ Custom  │
   │Calendar │  │          │ │ Tools   │
   │Drive    │  │          │ │         │
   └─────────┘  └─────────┘  └─────────┘

前提条件

npm または pnpm を使用する Node.js 18 以降
プロキシ対象となる 1 つ以上の MCP サーバー（stdio または HTTP）

インストール

ソースから

git clone https://github.com/steveweltman/4q-tokenz.git
cd 4q-tokenz

pnpm install
pnpm build

# Install to ~/.local/bin and configure
./install.sh

依存関係として

npm install -g 4q-tokenz

はじめに：Google Workspace の例

プロキシを介して Google Workspace（Gmail、Calendar、Drive）を LLM に接続する具体的な手順を説明します。

ステップ 1：Google 用の MCP サーバーを選択または構築する

Google API をラップする MCP サーバーが必要です。選択肢は次のとおりです。

@antidrift/mcp-google（推奨） — Google Workspace（Gmail、Calendar、Drive、Docs、Sheets）向けの MCP サーバー実装集です。このプロキシですぐに使用できます。
```
npm install @antidrift/mcp-google
# or
npx @antidrift/mcp-google --help
```
@modelcontextprotocol/server-gmail — Gmail のみを対象とする公式 MCP サーバーです
独自に構築する — 独自の API をラップする方法については、MCP 仕様を参照してください

ステップ 2：Google OAuth を設定する

Google Cloud Console にアクセスします
新しいプロジェクトを作成するか、既存のプロジェクトを選択します
次の API を有効にします。
- Gmail API
- Google Calendar API
- Google Drive API
OAuth 2.0 認証情報を作成します（種類：デスクトップアプリケーション）
認証情報の JSON ファイルをダウンロードします
Google MCP サーバーを一度実行して、token.json を生成します。
```
GOOGLE_CREDENTIAL_FILE=~/Downloads/credentials.json \
npx @antidrift/mcp-google
```
ブラウザーが開き、認証を求められます。完了すると、token.json がローカルに保存されます。

ステップ 3：プロキシを設定する

~/.config/4q-tokens/config.json を作成します。

{
  "upstreams": [
    {
      "name": "google-workspace",
      "transport": "stdio",
      "command": "npx",
      "args": ["@antidrift/mcp-google"],
      "env": {
        "GOOGLE_TOKEN_FILE": "~/.local/share/google-mcp/token.json",
        "GOOGLE_CONNECTORS": "gmail,calendar,drive"
      }
    }
  ],
  "searchLimit": 5,
  "callItemLimit": 30,
  "maxTextLength": 800,
  "maxOutputTokens": 10000,
  "idleTimeoutMs": 600000
}

ステップ 4：プロキシを起動する

mcp-proxy
# Or via systemd if installed:
systemctl --user start mcp-proxy

ステップ 5：LLM を接続する

LLM が http://127.0.0.1:9200/mcp を MCP サーバーとして使用するように設定します。次のツールが表示されます。

mcp_search — 自然言語でツールを検索します
mcp_call — ツールを呼び出します
mcp_schema — ツールの詳細を確認します

クエリの例：

mcp_search("send an email")
# Returns: google_send_email (Gmail)

mcp_call(ref="google_send_email", args={"to": "[email protected]", "subject": "Hello", "body": "Test"})

設定

環境変数を使ったクイックスタート

export MCP_PROXY_UPSTREAMS='[
  {
    "name": "google",
    "transport": "stdio",
    "command": "node",
    "args": ["/path/to/google/server.mjs"],
    "env": {
      "GOOGLE_TOKEN_FILE": "token.json"
    }
  }
]'

export MCP_PROXY_SINGLETON_PORT=9200
export MCP_PROXY_DASHBOARD_PORT=9100

node dist/index.js

設定ファイル（推奨）

~/.config/4q-tokens/config.json を作成します。

{
  "upstreams": [
    {
      "name": "google-workspace",
      "transport": "stdio",
      "command": "npx",
      "args": ["@antidrift/mcp-google"],
      "env": {
        "GOOGLE_TOKEN_FILE": "token.json",
        "GOOGLE_CONNECTORS": "gmail,calendar,drive"
      }
    },
    {
      "name": "external-api",
      "transport": "http",
      "url": "https://mcp.example.com/",
      "auth": {
        "apiKey": "MY_API_KEY_ENV_VAR"
      }
    }
  ],
  "searchLimit": 3,
  "callItemLimit": 20,
  "maxTextLength": 500,
  "maxOutputTokens": 8000,
  "idleTimeoutMs": 300000
}

次に、以下を実行します。

node dist/index.js

プロキシは、~/.config/4q-tokens/config.json が存在する場合はそこから設定を読み込み、存在しない場合は MCP_PROXY_UPSTREAMS 環境変数にフォールバックします。

設定リファレンス

上流サーバーの設定

{
  "name": "unique-id",
  "transport": "stdio" | "http",
  
  // For stdio transport:
  "command": "node",
  "args": ["path/to/server.mjs"],
  "cwd": "/working/dir",  // optional
  "env": { "KEY": "value" },  // optional
  
  // For http transport:
  "url": "https://example.com/mcp",
  "auth": {
    "apiKey": "ENV_VAR_NAME"  // reads from process.env[ENV_VAR_NAME]
  }
}

プロキシオプション

オプション	デフォルト	説明
`searchLimit`	3	mcp_search が返すツールの最大数
`callItemLimit`	20	mcp_call のレスポンスに含めるアイテムの最大数
`maxTextLength`	500	テキストフィールドを N 文字に切り詰めます（detail=false：500、detail=true：1500）
`maxOutputTokens`	8000	レスポンスサイズの上限
`idleTimeoutMs`	300000	N ミリ秒間非アクティブな上流サーバーとの接続を切断します（0 = 無効）

環境変数による上書き：

export MCP_PROXY_SEARCH_LIMIT=5
export MCP_PROXY_CALL_ITEM_LIMIT=30
export MCP_PROXY_MAX_TEXT_LENGTH=800
export MCP_PROXY_MAX_OUTPUT_TOKENS=10000
export MCP_PROXY_IDLE_TIMEOUT_MS=600000

マルチエージェントレーン（エージェントごとの分離）

複数のエージェントが1つのプロキシを共有する場合、各エージェントが参照・呼び出しできるのは自分のツールだけにする必要があります。4Q-Tokenz では レーン を使ってこれを実現します。レーンとは、/mcp/<agentId> という専用 URL で提供される、ツールレジストリの名前付きビューです。レーンに接続したエージェントは、参照を知っていても、ほかのレーンのツールを検出したり呼び出したりできません。

agent hope    -> entry "tokens-hope"   -> /mcp/hope    -> google-hope, hope-memory
agent clark   -> entry "tokens-clark"  -> /mcp/clark   -> google-clark, clark-memory
(no lane)     -> /mcp                  -> refused (HTTP 403)

レーンの定義

~/.config/4q-tokens/config.json の upstreams の隣に agents ブロックを追加します（または MCP_PROXY_AGENTS を JSON として設定します）。各レーンには、使用を許可する上流の プロバイダー と、必要に応じて拒否する個別のツールを指定します。

{
  "upstreams": [ ... ],
  "agents": {
    "hope": {
      "allow": ["google-hope", "hope-memory"],
      "deny": ["google-hope.drive_share", "google-hope.share_doc"]
    },
    "clark": { "allow": ["google-clark", "clark-memory"] }
  }
}

フィールド	説明
`allow`	このレーンで使用できる上流プロバイダー名（必須、最低1つ）
`deny`	任意。`allow` の適用後にレーンから除外する `provider.tool` または `*.tool` のエントリ。拒否は常に優先されます。一致するツールがない拒否エントリは起動時に警告として記録されるため、タイプミスがあっても暗黙のうちに許可されることはありません

エージェント ID は ^[a-z0-9_][a-z0-9_-]{0,63}$ に一致する必要があります。単純な配列形式（"hope": ["google-hope"]）も引き続き利用でき、許可のみを意味します。

フェイルクローズ動作

スコープなしのルート /mcp は 403 で拒否されます。レーンに紐付けられていないクライアントには、ツールプール全体が見えません。ローカル開発に限り、MCP_PROXY_ALLOW_UNSCOPED=1 を設定すると再び有効になります。
不明なレーン（/mcp/nobody）は 404 を返します。
プライマリになる stdio インスタンス（つまり、1つのクライアントにプール全体を提供するインスタンス）は、MCP_PROXY_ALLOW_UNSCOPED=1 が設定されていない限り、起動を拒否します。代わりにプロキシをサービスとして実行してください（シングルトンとブリッジモードを参照）。
ブリッジは、有効な MCP_PROXY_AGENT が設定されていない場合、起動を拒否します。

シングルトンとブリッジモード

1つの プライマリ インスタンスが上流への接続を所有し、MCP_PROXY_SINGLETON_PORT（デフォルトは 9200）でリッスンします。MCP_PROXY_SERVICE_MODE=1 を設定して、サービスとして実行します（HTTP のみで、stdio は使用しません）。stdio MCP サーバーとして起動される追加のインスタンスは、ロックファイルを通じて稼働中のプライマリを検出し、ブリッジ になります。ブリッジは、クライアントの stdio トラフィックを自身のレーンでプライマリに転送します。

MCP_PROXY_AGENT=hope node dist/index.js    # bridge: forwards to http://127.0.0.1:9200/mcp/hope

ロックファイルは MCP_PROXY_LOCK_DIR、それがなければ $XDG_RUNTIME_DIR、それもなければ /run/user/<uid>、さらにそれもなければ一時ディレクトリに置かれます。OpenClaw ゲートウェイなど、最小限の環境でプロキシを起動するホストでは XDG_RUNTIME_DIR が設定されないため、/run/user/<uid> へのフォールバックが用意されています。インスタンスがロックを取得した後にポートがすでに提供中だと判明した場合、クラッシュする代わりにロックを解放してブリッジになります。

OpenClaw でのエージェントの接続

OpenClaw にはエージェントごとの MCP 設定がなく、どのエージェントが stdio サーバーを起動したかも通知されません。そのため、分離には次の2つのレイヤーが必要です。

エージェントごとに1つの MCP サーバーエントリ を設定し、それぞれのレーンを環境経由で渡します。OpenClaw は MCP ツールを <serverName>__<tool> として公開するため、名前は英字で始めてください。

"mcp": {
  "servers": {
    "tokens-hope":  { "command": "/path/to/start-4q-tokens.sh", "env": { "MCP_PROXY_AGENT": "hope" } },
    "tokens-clark": { "command": "/path/to/start-4q-tokens.sh", "env": { "MCP_PROXY_AGENT": "clark" } }
  }
}

各エージェントで、グロブパターンを使ってほかのエージェントのエントリを拒否 し、それらがまったく見えないようにします（OpenClaw のツールポリシーでは、拒否が常に優先されます）。

"agents": { "entries": { "hope": { "tools": { "deny": ["tokens-clark__*"] } } } }

プロキシのレーンが強制適用の境界です。エージェントが何をしても、hope に紐付けられたブリッジがアクセスできるのは /mcp/hope だけです。OpenClaw の拒否リストは多層防御として、あるエージェントに別のエージェントのエントリが渡されるのを防ぎます。

分離の確認

プロキシログ：すべてのセッションにレーンが記録されます。例：HTTP session created: ... [hope]。通常の動作では、[open] セッションや Refused unscoped の行がないことを確認してください。
各エージェントから mcp_search を実行し、そのレーンのプロバイダーだけが表示されることを確認します。
あるエージェントから、別のレーンの参照を呼び出します。Tool not found が返される必要があります。

実行

単独実行（stdio トランスポート）

node dist/index.js

プロキシは stdio 経由で LLM に接続します。Claude やその他の MCP クライアントとともに使用してください。

Systemd ユーザーサービスとして

インストールスクリプトで設定できます（以下を参照）。手動で設定する場合：

~/.config/systemd/user/mcp-proxy.service を作成します：

[Unit]
Description=MCP Proxy Gateway
After=network.target

[Service]
Type=simple
ExecStart=%h/.local/bin/mcp-proxy
Restart=on-failure
RestartSec=5s
Environment="PATH=%h/.local/bin:/usr/local/bin:/usr/bin"

[Install]
WantedBy=default.target

有効化して起動します：

systemctl --user daemon-reload
systemctl --user enable mcp-proxy
systemctl --user start mcp-proxy

ログを確認します：

journalctl --user -u mcp-proxy -f

Prometheus メトリクス（ポート 9100）

ダッシュボードでは、Prometheus 互換の /metrics エンドポイントを公開しています：

curl http://localhost:9100/metrics

公開されるメトリクス：

メトリクス	種類	説明
`mcp_proxy_uptime_seconds`	gauge	プロセス起動からの経過秒数
`mcp_proxy_registered_tools`	gauge	レジストリに登録されているツール
`mcp_proxy_upstream_up`	gauge	アップストリームが接続中／アイドル状態の場合は 1、エラーの場合は 0
`mcp_proxy_upstream_tools`	gauge	アップストリームごとに検出されたツール
`mcp_proxy_calls_total`	counter	ツール、プロバイダー、ステータス別の呼び出し数
`mcp_proxy_call_duration_ms_total`	counter	呼び出し時間の累計（ミリ秒）
`mcp_proxy_output_bytes_total`	counter	出力バイト数の累計

Prometheus／Alloy の設定にスクレイプジョブを追加します：

scrape_configs:
  - job_name: mcp-proxy
    static_configs:
      - targets: ['localhost:9100']
    metrics_path: /metrics

HTTP サーバー（ポート 9200）

プロキシはデフォルトで、常にポート 9200 で HTTP トランスポートを起動します。別のポートを使用するには、MCP_PROXY_SINGLETON_PORT を設定します。これにより、複数のクライアントが 1 つのプロキシインスタンスに接続できます。クライアントは /mcp/<agentId> のレーンに接続します（マルチエージェントレーンを参照）。MCP_PROXY_ALLOW_UNSCOPED=1 を設定しない限り、スコープなしの /mcp ルートは拒否されます。

export MCP_PROXY_SINGLETON_PORT=9200
export MCP_PROXY_SERVICE_MODE=1
node dist/index.js &

# From another process, on a lane:
curl -X POST http://127.0.0.1:9200/mcp/hope -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {"protocolVersion": "2025-06-18", "capabilities": {}, "clientInfo": {"name": "curl", "version": "1"}}}'

トラブルシューティング

アップストリームの MCP サーバーに接続できない

ダッシュボード（デフォルトではポート 9100）またはデーモンのログで、サーバーログを確認してください：

journalctl --user -u mcp-proxy -e

プロキシは次の内容をログに記録します：

起動時のツール検出
エラーメッセージを伴う接続失敗
アップストリームの標準エラー出力（stdio サーバーからパイプ経由で受信）

プロキシがクラッシュまたはフリーズする

プロキシには、アップストリームの障害時に適切に縮退動作するための包括的なエラー処理が備わっています：

アップストリームのツール呼び出しが失敗すると、エラーがログに記録され、クライアントに返されます
検出時にすべてのアップストリームが失敗すると、起動は NO_UPSTREAMS で失敗します

未処理のエラーについては、次を確認してください：

journalctl --user -u mcp-proxy -n 50  # Last 50 lines

ツールがデータを返さない

ツールが null または不正な形式のデータを返した場合、出力整形機能が適切に処理します：

null の結果は [] を返します
文字列は {value: string} としてラップされます
表形式のデータに見える場合、CSV は自動的に解析されます
生のバイナリコンテンツ（画像、ファイル）は _rawContent を介して保持されます

ツールの応答が途中で切れているように見える場合は、mcp_call で detail=true を指定して再試行し、出力整形を無効にします：

mcp_call(ref="google_send_email", args={...}, detail=true)

セキュリティとネットワーク

セキュリティのため、プロキシは 127.0.0.1 のみ にバインドされます。デフォルトではネットワーク経由でアクセスできません。リモートからアクセスするには：

同じマシン：127.0.0.1:9200 でローカル接続します
リモートアクセス：Tailscale、SSH フォワーディング、または VPN トンネルを使用します
```
ssh -L 9200:127.0.0.1:9200 user@remote-host
```
Systemd サービス：デフォルトではローカルからのみアクセスできます。ファイアウォールルールは不要です
テナント分離：マルチエージェントレーンを参照してください。レーンはエージェントではなくプロキシによって適用され、スコープなしのルートはフェイルクローズします

既知の制限事項

テストは重点的なものであり、網羅的ではありません：pnpm test は、シングルトンロック、ブリッジの起動、レーン分離、拒否リストに関する回帰テストを実行します（Node 組み込みのテストランナーを使用し、追加の依存関係はありません）。アップストリームコネクターの動作は対象外です
レーンの適用はクライアントの接続方法に依存します：ブリッジまたはクライアントがレーンにバインドされている場合にのみ分離されます。プロキシはバインドされていないクライアントを拒否しますが、別のエージェントのレーンを意図的に指定したクライアントを止めることはできません

変更履歴

未リリース（次のバージョン：v1.23.0）

エージェントごとの分離が任意ではなく、必須になりました。

破壊的変更： スコープ指定のない /mcp ルートは、MCP_PROXY_ALLOW_UNSCOPED=1 を設定しない限り 403 で拒否されます。クライアントは /mcp/<agentId> を使用する必要があります
破壊的変更： ブリッジは MCP_PROXY_AGENT を読み取り、自身のレーンに接続します。有効なエージェント ID がない場合、起動を拒否します。サービス以外の stdio プライマリは、MCP_PROXY_ALLOW_UNSCOPED=1 を設定しない限り起動を拒否します
agents 設定にレーンごとの新しい deny リスト（provider.tool または *.tool）を追加しました。一致するツールがない項目については、起動時に警告します
README に「マルチエージェントレーン」セクションを追加し、レーン設定、フェイルクローズ動作、シングルトンモードとブリッジモード、OpenClaw との接続方法について説明しました
レーン分離、フェイルクローズの経路、拒否リストの動作に関するテストを追加しました

v1.22.3

@modelcontextprotocol/sdk を 1.31.0 から 1.32.1 に更新し、proxy-addr（express 経由）を含む、すべての pnpm audit --prod の検出事項を解消しました

v1.22.2

シングルトンロックの修正を含むビルドを識別できるよう、バージョンを更新しました

シングルトンロックディレクトリの修正（v1.22.1 と v1.22.2 の間）

修正：環境変数が最小限の状態（たとえば OpenClaw ゲートウェイによって XDG_RUNTIME_DIR が設定されていない状態）で起動したプロキシは、一時ディレクトリ内のロックを探していました。稼働中のプライマリを見つけられず、2 つ目のプライマリになろうとして EADDRINUSE でクラッシュし、クライアントには MCP error -32000: Connection closed と表示されていました。ロックディレクトリは /run/user/<uid> にフォールバックするようになり、ロックを獲得したインスタンスが、そのポートがすでに使用中だと検出した場合はクラッシュせずにブリッジとして動作します
回帰テストを追加しました（pnpm test）

v1.22.1

リリース前評価（OWASP Top 10 2025、OSV.dev、GCVE）に基づくセキュリティ強化：

ダッシュボード：/api/status から Access-Control-Allow-Origin: * を削除し、監査ログデータからツール呼び出しの args を返さないようにしました。以前は、任意のウェブサイトが 127.0.0.1:9100 から最近の呼び出し引数を読み取ることができました
新しい src/host-guard.ts：/mcp とダッシュボードは、Host または Origin がループバック以外のリクエストを拒否します（403）。これにより、DNS リバインディングとクロスサイトブラウザーアクセスを防止します
シングルトンロックファイルは、設定されている場合は $XDG_RUNTIME_DIR に作成され（設定されていない場合は一時ディレクトリにフォールバック）、モード 0600 で作成されるようになりました
OSV.dev：インストール済みパッケージ 93 件すべてでアドバイザリ 0 件。pnpm audit でも問題は検出されませんでした

v1.22.0

主要な依存関係を更新しました：zod 3.25 → 4.6、typescript 6.0 → 7.0、@types/node 25 → 26
zod 4 への移行：z.record の呼び出しで、キーのスキーマを明示的に渡すようになりました（src/types.ts）
@modelcontextprotocol/sdk を ^1.30.0 から ^1.31.0 に更新しました
pnpm のオーバーライドを強化しました：hono >=4.13.5、fast-uri >=4.1.4、ip-address >=10.5.1。さらに qs >=6.16.0 を追加し、重大度の高い 2 件と中程度の 7 件のアドバイザリを解消しました（すべて MCP SDK 経由の間接依存関係）
pnpm audit で問題がないことを確認しました

v1.21.2

v1.21.1 の修正が不完全だった問題を修正：hono の pnpm オーバーライド（>=4.12.25）では、脆弱性のある 4.12.x リリースが引き続き解決されていたため、>=4.12.34 に引き上げました
@modelcontextprotocol/sdk 経由の間接依存関係すべてを対象に、@hono/node-server >=1.19.15、fast-uri >=3.1.5、ip-address >=10.3.1、body-parser >=2.3.0 の pnpm オーバーライドを追加しました。これにより、重大度の高い CVE 3 件と中程度／低い CVE 6 件（DoS、ReDoS、SSRF に関連する解析上の不具合）を解消しました
@modelcontextprotocol/sdk を ^1.26.0 から ^1.30.0 に更新しました
解決されたすべての依存関係のバージョンについて、pnpm audit と OSV.dev で問題がないことを確認しました

v1.21.1

hono の依存関係パッチを試みました（pnpm override: hono >=4.12.25）。オーバーライドの範囲が広すぎて脆弱性のあるバージョン範囲を解消できず、上記の v1.21.2 で完全に解決しました

v1.21.0

detail=true を指定しても、ツール出力のテキストフィールドが切り詰められなくなりました

v1.20.0

エージェントごとのレーン分離：/mcp/{agentId} による URL ルーティング、フィルタリングされたツールレジストリのビュー、MCP_PROXY_AGENTS 設定を追加しました

v1.19.0

ダッシュボードのポート（デフォルトでは9100）に Prometheus の /metrics エンドポイントを追加
次のメトリクスを公開します：mcp_proxy_uptime_seconds、mcp_proxy_registered_tools、mcp_proxy_upstream_up、mcp_proxy_upstream_tools、mcp_proxy_calls_total、mcp_proxy_call_duration_ms_total、mcp_proxy_output_bytes_total
カウンターはプロセスの存続期間中保持されます。Prometheus/Alloy でスクレイピングし、Grafana で可視化できます

v1.18.0

@xenova/transformers を完全に削除し、protobufjs/ONNX ランタイムのサプライチェーンを排除
純粋な語彙検索（BM25）に切り替え。ツールのトークンは起動時に事前計算され、クエリごとのオーバーヘッドはありません
英語のツールカタログに対する mcp_search の品質に変更はありません
初回実行時の約90MBのモデルダウンロードと、すべてのネイティブモジュール要件を削除

v1.17.1

レジストリのビルド時にツールのトークンセットを事前計算。語彙スコアリングでは、クエリごとに再トークン化せず、キャッシュを参照するようになりました
クエリ埋め込み用の LRU キャッシュを追加（埋め込み機能は v1.18.0 で完全に削除）

v1.17.0

より軽量な英語最適化済みの埋め込みモデルに切り替え、コールドスタート時のダウンロード量を約380MB削減（埋め込み機能は v1.18.0 で完全に削除）

v1.16.0

@modelcontextprotocol/sdk を ~1.22.0 から ^1.26.0 に更新。重大度の高いCVEを3件解消：ReDoS、クライアント間のデータ漏えい、DNSリバインディング
pnpm のオーバーライドを追加：protobufjs >=7.5.8。@xenova/transformers の推移的依存関係チェーンにある、任意コード実行の重大な脆弱性と複数の重大度の高いCVEを解消
pnpm のオーバーライドを追加：qs >=6.15.2。express の推移的依存関係にある中程度のDoS脆弱性を解消

謝辞

MCP Proxy Gateway は @arvoretech/mcp-proxy のフォークです。元々は João Augusto 氏と Árvore Educação が作成しました。

フォーク後、以下の機能を追加・拡張しました：

HTTP ブリッジのシングルトンモード
アイドル状態のサーバーの解放
包括的なエラー処理
設定ファイルのサポート
Systemd との統合

ライセンス

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

Markdown 対応

ログインしてコメント

基本情報

作者: steveweltman
言語: node
バージョン: 1.14.1
トランスポート: stdio
掲載日: 2026年5月8日
最終更新: 1 週間前
公式 Registry: io.github.steveweltman/4q-tokenz

問題を報告

MCP は初めてですか？

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

入門ガイドを読む

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。