MCP Router レビュー: MCP サーバーをデスクトップで束ねる管理アプリの実像
A Unified MCP Server Management App (MCP Manager).
ひと目でわかる
- これは何？
- 複数の MCP サーバーを Projects と Workspaces で整理し、トークン経由で CLI から接続する TypeScript 製デスクトップアプリ。便利さの中心はローカル完結の管理画面にあり、ライセンスは Sustainable Use License で OSI 承認のオープンソースではない。
- 誰に向いている？
- MCP サーバーが増えて設定ファイルの手編集に行き詰まり、Windows か macOS のデスクトップで Projects と Workspaces を使い分けたい個人や小規模チームには向く。ヘッドレス運用や Linux 環境、設定を Git で宣言的に管理したい構成には向かない。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 43 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
MCP Router が埋めるのは「サーバー一覧が散らかる」問題
MCP のクライアントは増えたが、サーバーの登録先はクライアントごとにバラバラの JSON だ。Claude 用、Cursor 用、Cline 用と設定ファイルが分かれ、同じサーバーを何度も書き、使わないツールまで毎回コンテキストに載る。MCP Router はこの散在を 1 つのデスクトップアプリに集める。README が挙げる機能は 3 つで、任意の MCP サーバーへの接続、Windows と macOS のクロスプラットフォーム対応、そして Projects と Workspaces によるコンテキスト整理だ。対象は MCP サーバーを 2 つ 3 つと試す段階を過ぎ、常用のツール群を案件ごとに切り替えたくなった人になる。逆にサーバーが 1 つだけなら、このアプリを挟む理由は薄い。
中核は Projects と Workspaces の二層構造
README の説明では、Projects は MCP サーバーをまとめる単位、Workspaces はブラウザのプロファイルに例えられたモード管理の単位とされている。サーバー単位のオンオフだけでなく、サーバーが公開するツールを個別に切り替えられる点が実務では効く。読み取り専用のツールだけ有効にして書き込み系を切る、といった運用がダッシュボード上で完結する。README はこの切り替えを「Toggle tools on/off per server」と表現している。設定ファイルを開かずにツールの露出を変えられるのは、MCP のコンテキスト消費を抑える直接的な手段になる。ただし README は Projects と Workspaces の関係を図で示すだけで、両者がどう重なるのか、片方だけでも成立するのかまでは文章で説明していない。ここは導入前に自分の運用に当てはめて確かめる必要がある。
接続はトークンと CLI 経由、設定はローカルに閉じる
クライアント側から MCP Router へ繋ぐ手順は README にコマンドとして載っている。カスタムアプリを追加したときに発行されるトークンを環境変数に入れ、CLI で接続する。
export MCPR_TOKEN="mcpr_your_token" npx -y @mcp_router/cli connect
Project を指定する場合は --project を付ける。
npx -y @mcp_router/cli connect --project <project-name>
つまりクライアントは個々の MCP サーバーを直接知るのではなく、MCP Router を経由してツールに到達する。サーバーの追加方法として README は DXT、JSON、手動の 3 つを挙げており、リモートとローカルの両方に対応するとしている。データの扱いについては、リクエストログ、設定、サーバーデータは端末上に留まり、API キーや認証情報も外部送信されないと README は明記している。デスクトップアプリのソースが公開されているため、この主張をコードで検証できるというのが README の立場だ。
ログと統計は付属するが、数値の裏付けは README にない
README にはリクエストログと統計を表示する画面の画像が掲載され、機能として「Comprehensive Logging & Analytics」が挙げられている。どのサーバーがどれだけ呼ばれたかを後から見られるのは、使っていないサーバーを削る判断材料になる。ただし README はログの保持期間、保存先のパス、エクスポート形式、統計の集計粒度を一切書いていない。スクリーンショット以上の情報がないため、監査目的でログを長期保存したい用途に耐えるかは、この資料からは判断できない。ログを外部の可観測性基盤へ送る口が用意されているかも不明だ。ローカルに閉じる設計を売りにしている以上、外部送信の口が無いこと自体は一貫しているが、それは同時にログを他のツールと突き合わせにくいことを意味する。
向かない場面: ヘッドレス環境と宣言的設定
対応 OS は README の記載では Windows と macOS に限られる。Linux のデスクトップやサーバー上で動かす前提は読み取れない。CI やコンテナの中で MCP サーバー群を扱いたい場合、GUI を伴うデスクトップアプリという形態そのものが噛み合わない。もう一点、設定をコードとして Git で管理したいチームにも向かない。Projects や Workspaces の実体がどのファイルにどう保存されるかは README に記述がなく、GUI 上の操作が正となる設計に見える。レビューや差分管理を設定ファイルで回している現場では、GUI が唯一の編集面になること自体が摩擦になる。CLI は connect 用であり、サーバー定義を宣言的に流し込む手段は README には示されていない。
代替としてのクライアント内蔵の MCP 設定
比較対象として素直なのは、Cursor や Cline といったクライアントが持つ MCP 設定そのものだ。違いは管理の所在にある。クライアント内蔵の設定は、そのクライアントの中だけで完結する。サーバーの追加もツールの有効化もクライアントの UI か設定ファイルで行い、他のクライアントには反映されない。MCP Router は逆で、サーバー定義とツールのオンオフをアプリ側に集約し、複数クライアントは同じトークンで同じ構成を参照する。クライアントを乗り換えても構成が残るのは利点だが、そのぶん MCP Router が落ちれば全クライアントのツールが同時に止まる。単一障害点を一箇所に集める設計だと言える。1 つのクライアントしか使わないなら、内蔵設定のほうが依存も層も少ない。
ライセンスと更新のコスト
リポジトリのライセンス表記は NOASSERTION で、README は Sustainable Use License とだけ述べ、詳細は LICENSE.md を参照するよう求めている。これは OSI 承認のオープンソースライセンスではない種類の表記であり、社内配布や再配布、ホスト型サービスとしての提供が許されるかは LICENSE.md を読んで自組織の用途に照らす必要がある。ここで法的助言はできない。更新面では、リリースは v0.6.1 が 2025 年 11 月、v0.6.2 が 2026 年 1 月、v0.6.3 が 2026 年 6 月と、0.x 系のまま数か月間隔で続いている。0.x である以上、設定の保存形式や CLI の引数がマイナー更新で変わる可能性は残る。導入するなら、まず releases ページから自分の OS 向けの配布物を取得し、LICENSE.md を確認し、そのうえで MCPR_TOKEN を設定して npx -y @mcp_router/cli connect が自分のクライアントから通るかを確かめる順序になる。
編集部の結論
MCP サーバーが増えて設定ファイルの手編集に行き詰まり、Windows か macOS のデスクトップで Projects と Workspaces を使い分けたい個人や小規模チームには向く。ヘッドレス運用や Linux 環境、設定を Git で宣言的に管理したい構成には向かない。導入前に releases ページの配布物が自分の OS 向けか、LICENSE.md の Sustainable Use License が自分の用途（特に再配布やホスト型サービス提供）を許すかを確認し、そのうえで npx -y @mcp_router/cli connect が自分のクライアントから通るかを試す。
コミュニティノート