Toolport: MCP 設定と権限境界と token 税を一か所で扱う

MCP 周辺を見ていると、同じ種類の問題に何度もぶつかります。

AI client ごとに server を別々に設定する必要がある;
server をいくつか増やすだけで tool definition が context をかなり食う;
OAuth、API key、危険 tool、監査情報が各 client に散らばって管理しにくい。

今日メモしておきたい tsouth89/toolport は、まさにこの 3 点をまとめて扱う project です。そして作り方がかなり infrastructure 寄りです。

これは単一 agent 向け plugin ではなく、単なる MCP server カタログでもありません。位置づけは local-first MCP gateway です。

server 接続、tool 発見、client への割り当て、credential 注入、リスク表示を 1 つの層にまとめる。

GitHub repository page、README、latest release を 2026-07-02 時点で確認すると、この project はおよそ 50 stars、11 forks。GitHub 上の primary language は現在 TypeScript ですが、実体は Tauri desktop app + Rust gateway という構成です。repository 作成日は 2026-06-19、直近の公開 code push は 2026-07-02。最新 release は v0.9.4 で、公開日は 2026-07-01、license は MIT です。

Project overview

項目	内容
Repository	tsouth89/toolport
位置づけ	複数 AI client 向け local MCP gateway
Stars	50
Forks	11
Repository の primary language	TypeScript
実際の中核構成	Tauri desktop app + Rust gateway
Repository 作成日	2026-06-19
直近の公開 code push	2026-07-02
Latest version	v0.9.4
Release date	2026-07-01
Code license	MIT
中心の考え方	1 つの入口で複数 MCP server を束ね、client ごとに必要な tool だけ見せる

これはまず「MCP にどう接続するか」より、「接続後にどう暴走させないか」を扱っています

最近の MCP tool は、接続そのものよりも接続後の膨張が問題になりがちです。

Codex、Claude、Cursor、VS Code、Gemini CLI などを並行して使っていると、すぐに次のような状況になります。

同じ GitHub、Sentry、Stripe、database server を何度も設定する;
ある client は毎回すべての tool definition を context に入れてしまう;
account credential が各 config file に分散する;
どの client がどの server や destructive tool を見えているのか把握しにくい。

Toolport の前提はかなり明快です。

MCP を client ごとの小さな設定ではなく、共有基盤として扱う。

ここがこの project の一番大きい価値だと思います。

一番おもしろいのは lazy discovery: 最初に出すのは 3 つの meta-tools だけ

README で特に見るべきなのは、対応 client の数より token 税への向き合い方です。

Toolport は下流の全 tool を最初から全部見せるのではなく、標準では lazy discovery を使います。gateway が先に公開するのは次の 3 つだけです。

toolport_status
toolport_search_tools
toolport_call_tool

agent はまず検索し、それから必要な tool を呼ぶ。つまり巨大な tool catalog を最初から context に流し込みません。

この設計はかなり筋が良いです。

MCP でありがちなのは、tool が増えるほど能力が上がるというより、先に context cost が増えることだからです。

README にある benchmark では、3 つの server と 62 個の tool だけでも definition 部分で約 24000 tokens かかり得る一方、按需 discovery に切り替えるとそのコストは数百 token まで下がります。説明では、同程度の task success を保ちながら総 token 使用量を最大で 9 割前後削減できるとされています。

これは「model が賢くなった」系の話ではなく、context の入口そのものを細くしたという種類の改善です。

「複数 client で同じ server 群を共有する」を主役に置いています

Toolport の 2 つ目の実用ポイントは、単一 host の補助機能に留まっていないことです。

README にある client 一覧には現在、

Codex
Claude Desktop
Claude Code
Cursor
VS Code
Gemini CLI
Windsurf
Continue
Zed
Warp

などが含まれています。

つまり価値の中心は、どれか 1 つの agent を強化することではなく、

一度つないだ server 群を複数の host で再利用する

という層を切り出したことにあります。

複数 client を併用している人にとって、これはかなり大きいです。JSON、TOML、YAML の差分を毎回覚える必要がなく、OAuth や API key の設定を何度も繰り返さなくてよくなります。

README では、各 client の install doc にある設定断片を貼り付けるだけで形式を推定して prefill する、という説明まであります。この手の小さな摩擦を潰しているのが良いです。

client ごとの profile 分離がかなり大事です

MCP tool が増えると、すぐに権限境界の問題が出ます。

すべての AI client が同じ server を見る必要はありません。もっと言えば、すべての coding agent が支払い、production database、ticket system、destructive tool に触れられるべきでもありません。

Toolport はここで per-agent scoping を用意しています。profile ごとに server を分け、ある client には本当に必要なものだけ見せられます。

この発想はかなり堅実です。境界を prompt に頼るのではなく gateway 層に作るからです。

ある client からその tool 自体が見えなければ、誤呼び出しの余地がそもそも減ります。

secrets と安全まわりの扱いも、かなり engineering 寄りです

Toolport の印象が infrastructure に近いのは、安全の話を marketing 文句で終わらせていないからです。

README では次のような点が整理されています。

OAuth や API key は gateway 側で 1 回設定する;
credential は client config に散らさず OS keychain に置く;
destructive tool を一括で隠せる;
call、latency、error rate を記録する;
tool definition の変化や怪しい schema/description を検知する;
tool が返す injection 風 text を「外部 data」として扱う。

ここで大事なのは、完全防御を約束していることではありません。

gateway が経路上にいるなら、少なくとも一部の governance と audit を担うべきだ

という態度を明確にしていることです。これはかなり信頼しやすいです。

ひとつ面白いのは、対外名は Toolport でも内部名に Conduit が残っていることです

README を読むと、今の表向きの名前は Toolport ですが、binary 名、env var、説明の一部にはまだ conduit-gateway や CONDUIT_PROFILE が残っています。

これは project の今の状態をかなり正直に示しています。

まだ速く進化していて、branding と internal implementation が完全には揃い切っていない。

私はむしろこの手触りが嫌いではありません。文書で明示されていれば十分扱えるし、同時に「今もかなり積極的に変わっている project だ」という目安にもなります。

どんな人に向いているか

特に相性が良さそうなのは、次のようなケースです。

複数の AI client を並行して使っている;
すでに複数の MCP server を接続している;
tool definition で token を無駄にしたくない;
credential、tool 境界、audit を 1 か所に寄せたい;
「どの client が何を見えるか」を明示的な設定にしたい。

逆に、単一 client に単一 server を時々つなぐだけなら手書き config でも足りるかもしれません。ただ、server 数か client 数のどちらかが増えた瞬間に、この層の価値はかなり上がります。

まとめ

tsouth89/toolport の良さは、単に MCP gateway を作ったことではありません。

より重要なのは、これまで別々に面倒だった問題を 1 つの設計にまとめていることです。

tool definition が太すぎることによる token 税;
複数 client への重複設定;
secrets、危険 tool、audit 境界の散乱。

その答えもかなり節度があります。もっと大きな agent platform を作るのではなく、agent と下流 MCP server の間に、local で共有できて、境界と運用を持てる gateway を置く。

複数 client と複数 server を本気で回し始めた人にとって、これは「また 1 つ新しい agent」より、ずっと長く効く infrastructure だと思います。