MCPサーバーを増やすと便利になる——とは限らない。当サイトでこれまで測ってきた範囲でも、ツールを24本持つサーバーが21,831トークン、7本しかないサーバーが24,665トークンを文脈に常駐させていた。ツールの数と重さは比例せず、しかもどちらも増える一方というのが実情だ。
superdesigndev/treg はその逆を行く。「OpenRouter の、モデルではなくツール版」を名乗り、約2,600のAPIエンドポイントをエージェントから呼べるようにする。Semrush も Crunchbase も Apollo も、アカウントを持たずに1回いくらで叩ける、という触れ込みだ。
2,600という数を聞いた瞬間に気になるのは、それを一体どうやってエージェントに見せるのかだった。全部をMCPツールにしたら文脈が爆発する。そこで実際に導入してツール定義を取り出し、バイト数を数えた。ついでに LICENSE も読んだら、GitHub の表示とは違うものが書いてあった。
30秒でわかる
・MCPツールは13本・合計11,335バイト（約2,834トークン）。うちカタログを使うのに要るのは3本・約1,238トークンだけ
・2,600本を個別ツールにしたら約566,000トークン。カタログ3点の457倍で、どの文脈長にも載らない
・GitHub は「Apache 2.0 license」と表示するが、優先する追加条項が2件ある。第三者へのホスティング提供は要許諾でOSI準拠ではない
・import-linter のアーキテクチャ契約15本が全部無傷。296ファイル・2,077依存を解析して破れ0件
・配布版とリポジトリで39モジュール違う。どちらも 0.22.0 を名乗り、タグは1つも無い
・treg.to はこの環境から到達できず、カタログ検索も実呼び出しも未検証
MCPサーバーそのものの作り方はMCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアルにまとめてある。本記事はその枝として、ツールを増やさずに機能を増やすという方向の実装例を測る。
treg が解こうとしている問題
まず正体の確認から。README の冒頭2文はこうだ。
OpenRouter, but for agent tools instead of models. Point an agent at one base URL with one token and it can do the job: a curated catalog of thousands of endpoints across many providers
つまりツールのゲートウェイであって、MCPサーバーの一種ではあるが本体はカタログとその課金基盤にある。狙いも明快に書いてある。
The tools an agent needs for real work sit behind subscriptions nobody buys for a single run — Semrush $139/mo, Moz $99/mo, Crunchbase $99/mo, Apollo $59/seat
1回のリサーチのために月139ドルのサブスクは買わない。treg がそのアカウントを持っていて、1コール数セントで売る、という構造だ。自分のチームのAPIキーやCLIを登録して、資格情報をサーバー側に置いたままメンバーのエージェントに使わせる、という使い方も用意されている。
導入は PyPI から通る。リポジトリを直接入れようとすると失敗するので、そこは先に書いておく。
# クローンから直接は通らない
pip install ./treg
# RuntimeError: Dashboard assets are missing.
# Run bash scripts/build-dashboard.sh before uv build.
# PyPI 版は通る
pip install tools-registry # CLI のみ：11秒・18パッケージ・83MB
treg --version # → treg 0.22.0
実測値を並べておく。
| 項目 | 実測値 |
|---|---|
| バージョン | 0.22.0（PyPI tools-registry / リポジトリも同じ表記） |
| CLI のみの導入 | 11秒 / 18パッケージ / 83MB |
サーバー一式（[server]） |
63パッケージ / 249MB |
| リポジトリのPython | 277ファイル / 90,347行 |
| テストファイル | 193本 |
| star / fork / open issue | 4,600 / 379 / 11 |
| ライセンス | Apache-2.0 ＋追加条項2件 |
CLI だけなら FastAPI もDBドライバも入らず83MBで済む。README の「pip install tools-registry alone gives just the treg command」という説明と実測が一致した。パッケージ数で3.5倍、容量で3.0倍の差がある。
--help を見ると、サブコマンドはカタログ（catalog / call / balance / topup / review）、自分の道具（tool / skill / secret / connections / hub）、手元での実行（cli / with / serve）、一括登録（scan / upload）、チーム管理（audit / org / invites / agents）と系統立っている。treg with は「チームの資格情報を注入して任意のコマンドを走らせる」もので、treg claude や treg node app.js のように使う。
ここでこの環境の壁に当たった。treg.to は egress プロキシに遮断されていて到達できない。
treg catalog search "backlinks for a domain"
# httpcore.ProxyError: 403 Forbidden
# （整形されたエラーではなく Python のトレースバックがそのまま出る・終了コード1）
ネットワークが無いときにスタックトレースを吐くのは、エージェントに実行させる前提のCLIとしては扱いづらい。エージェントは「ProxyError」を読んで何をすべきか判断できない。ここは素直に改善点だと思う。
というわけでカタログ検索・課金・実際のツール呼び出しはすべて未検証になった。以降は配布物とリポジトリのソースから測れることだけを書く。公称の「約2,600エンドポイント」も、ソース内のコメントと README の記述であって、成果物から数え直せる数ではない（カタログ本体はサーバー側のデータだ）。
MCPツールを13本に畳むと何トークン得か
ここが本題だ。treg は CLI とは別に MCP の入口を持っている。src/treg/mcp.py の冒頭に、その設計意図がはっきり書いてある。
The catalog is data. One tool searches it, one reads an entry, and one calls an endpoint. Exposing every endpoint as its own MCP tool would flood the model’s context with 2,600 schemas and make the catalog unusable, which is the opposite of the point.
カタログはツールではなくデータである。この一文が設計の全部だ。では実際にいくつのツールが出ているのか。サーバー一式を入れて list_tools() を呼んだ。
from treg.mcp import mcp
tools = await mcp.list_tools() # → 13
13本だった。名前と定義のバイト数（name ＋ description ＋ input_schema）はこうなる。
| ツール | バイト数 | 役割 |
|---|---|---|
call |
3,916 | カタログのエンドポイントを呼ぶ |
hub_create |
1,504 | ツールを組み合わせたツールを公開する |
feedback |
1,293 | 問題・要望を送る |
call_media |
756 | 画像・音声・動画を伴う呼び出し |
hub_update |
663 | 公開物の更新 |
review |
619 | 呼び出し結果の評価 |
catalog_search |
573 | やりたいことで道具を探す |
catalog_request |
488 | 無い道具をリクエストする |
catalog_get |
464 | エントリを1件読む |
resources_list |
364 | リソース一覧 |
my_tools |
305 | 自分のチームの道具 |
balance |
227 | 残高 |
hub_mine |
163 | 自分の公開物 |
| 合計 | 11,335 | 約2,834トークン |
※ トークン換算は heuristic-jp-v1（CJK 1文字=1トークン / ASCII 4文字=1トークン）。tiktoken の cl100k_base は BPE辞書の取得先が遮断されていて使えなかった
カタログを使うのに本当に要るのは3本（catalog_search ＋ catalog_get ＋ call）で、合計 4,953バイト＝約1,238トークン。残り10本は残高・レビュー・公開といった口座まわりの操作だ。
では「全部をツールにしたら」どうなるか。13本の平均は871バイト／本なので、2,600本なら 約2,264,600バイト＝約566,000トークン。カタログ3点の 457倍にあたる。いちばん小さい hub_mine（163バイト）を全部に当てはめる最も楽観的な見積もりでも約105,950トークン（86倍）で、どのみち文脈には載らない。
docstring が言う「make the catalog unusable」は比喩ではなく、数えると本当に不可能だった。
この数字を、当サイトがこれまで実測してきたMCPサーバーと並べてみる。
| サーバー | ツール数 | 常駐トークン |
|---|---|---|
| draw.io MCP | 7 | 24,665 |
| Notion MCP | 24 | 21,831 |
| Backlog MCP | 62 | 11,710 |
| treg | 13 | 約2,834 |
※ treg 以外は各記事での計測値で、トークナイザが異なる可能性がある。桁の比較として読んでほしい
ツール数が多ければ重い、という単純な話ではないことがよく分かる。Backlog は62本で11,710トークン、draw.io は7本で24,665トークン。重さを決めるのはツールの数ではなく、1本あたりの説明文とスキーマの長さだ。treg の13本が軽いのは、個々のエンドポイントの仕様をツール定義ではなくカタログのデータ側に置いたからで、設計の方向が違う。
ツール1本"] C --> D["ツールが増えるほど
文脈が重くなる"] B -->|"treg の設計"| E["カタログはデータ
ツールは13本固定"] E --> F["catalog_search
やりたいことで探す"] E --> G["catalog_get
1件読んで価格を見る"] E --> H["call
idを指定して呼ぶ"] F --> I["約2,600本ぶんを
約1,238トークンで賄う"] G --> I H --> I
同じ docstring には、もうひとつ実装上の判断が書いてあった。お金・テナント・資格情報に触る処理は、すべて treg 自身のHTTP APIへ httpx.ASGITransport で戻すという方針だ。
/call/already enforces the per-member tool ACL, deny rules, the per-user daily cap, the platform daily cap, the balance reserve and the settle — a second entrance that re-implemented any of that is exactly how one copy quietly stops being enforced.
MCPという第2の入口を作るときに、権限チェックを書き直さずに既存のAPIを経由させる。ソケットを使わないプロセス内の往復なので「測ったら1ミリ秒未満」とも書いてある。一方カタログの読み取りだけは catalog_store から直接読む——こちらは性能上の選択で、権限の判断は伴わないから、と理由まで添えられている。
「ヘッダは身元ではない（Headers are not identity）」という節もあり、MCPリクエストのベアラートークンはクライアント由来の入力であって、形が正しいからといって信用せず毎回DBで検証する、と明記されている。
アーキテクチャの契約が本当に守られているか
docstring に立派なことが書いてあるのと、コードがそうなっているのは別の話だ。幸い treg は import-linter の契約を pyproject.toml に持っているので、実行して確かめられる。
lint-imports --config pyproject.toml
結果は 296ファイル・2,077依存を解析して「Contracts: 15 kept, 0 broken」。15本すべて無傷だった。契約の名前がそのまま設計方針になっている。
・Money domain does not depend on best-effort audit（課金は「ベストエフォートの監査」に依存しない）
・Governance policies do not import web frameworks（ガバナンスのポリシーはWebフレームワークを import しない）
・Catalog domain is a leaf: no outer layers, no sibling domains（カタログは葉：外側の層も兄弟ドメインも参照しない）
・Lightweight CLI modules do not import server dependencies（軽量CLIはサーバー依存を import しない）
・Upstream infrastructure does not depend on HTTP adapters（上流インフラはHTTPアダプタに依存しない）
4つめは、先ほど実測した「CLIのみ83MB・サーバー込み249MB」をコード側から保証している契約だ。CLIがサーバー依存を引いてしまえば軽量インストールは成立しないので、それを機械で止めている。宣言と実測が噛み合っている例として気持ちがいい。
90,347行のPythonに対して契約が1本も破れていないのは、素直に品質の高さを示している。ただしこれを走らせるにはリポジトリのソースを指す必要がある。配布版のパッケージに対して実行すると Module 'treg.domain.table' does not exist. で止まる——その理由が次の話になる。
配布版とリポジトリが同じ 0.22.0 で違う中身
リポジトリの src/treg 配下には 277本の .py がある。PyPI から入れた site-packages/treg には 238本。差は 39本で、逆向きの差（配布版にだけあるもの）は 0本だった。
内訳はこうなる。
| 分類 | 本数 | 中身 |
|---|---|---|
| alembic の移行 | 14 | 0051〜0062系。DBスキーマの追加分 |
| application | 15 | web_arena* 4本、onboard/* 5本、table.py、catalog_search.py ほか |
| domain | 5 | table/、web_arena* 2本、catalog/find_recall.py ほか |
| routers | 3 | table.py、web_arena.py、activity.py |
| infra | 2 | llm.py・embed.py |
まとまりとしては3つの機能群だ。web_arena（アリーナ／リーダーボード）、table（/table/<tool id> を行と列で返す機能・2026-09-26 追加）、onboard（初回セットアップ）。
注意したいのは infra/llm.py と infra/embed.py、それに application/catalog_search.py と domain/catalog/find_recall.py が配布版に入っていないことだ。これらは README の看板である「やりたいことで道具を探す」検索の実装側にあたる。ホスト版 treg.to はリポジトリのコードで動いているはずなので利用者には影響しないが、PyPI から自前レジストリを立てる場合は話が変わる可能性がある。ここは実際に自前レジストリを起動して確かめられていないので、未検証と書いておく。
そして一番効いてくるのは、両方とも 0.22.0 を名乗っていることだ。リポジトリにタグは1つもない。domain/table が入った feat(table): /table/<tool id>... と、release: 0.22.0 は同じ 2026-09-26 のコミットで、以降バージョンは上がっていない。つまりバージョン番号を見ても、どちらの中身を持っているか判別できない。
なお配布版でも treg.cli / treg.mcp / treg.api はいずれも正常に import できた。機能群がまるごと入っていないので、参照切れは起きていない。壊れてはいない、という点は正確に書いておく。
GitHub の「Apache 2.0」表示の裏にあるもの
GitHub のサイドバーには「Apache 2.0 license」と出る。LICENSE ファイルに Apache-2.0 の全文が複製されているので、検出器はそう判定する。
ところが冒頭にこう書いてある。
This software is licensed under the Apache License, Version 2.0 (reproduced in full below), with the following Additional Terms. The Additional Terms take precedence over the Apache License to the extent of any conflict.
追加条項が2件あり、競合する場合はそちらが優先する。
条項1：ホスティング制限。 自組織内での商用利用と、自前のレジストリを自チームのために運用することは「expressly permitted and encouraged」と明示的に許可されている。禁止されるのは、第三者に対してホスト型・マネージド型・組み込み型のサービスとして提供することだ。SaaS製品、マネージドレジストリ、そして販売・ライセンス供与される製品やサービスの一部として使うには書面による事前許可が要る。
条項2：コントリビューター条項。 コードやドキュメントを寄与すると、(a) 同じ条件でプロジェクトにライセンスし、(b) licensor が自身のホスティング提供を含めて商用利用してよいことに同意したとみなされる。
実務的にどう読むか。自社の中でエージェントに使わせるぶんには Apache-2.0 とまったく同じで、何も気にしなくていい。自前レジストリを立てて社内に配るのも許可されている。引っかかるのは「顧客に出す製品の一部に組み込む」ケースで、ここは要許諾になる。
つまり OSI 準拠のオープンソースではない。pyproject.toml の license も { file = "LICENSE" } で、SPDX の識別子を名乗っていない——ここは誠実だと思う。ただし GitHub のバッジだけを見て「Apache だから自由に組み込める」と判断すると踏み外す。
リポジトリのバッジ表示と実際のライセンス条件がずれる話は当サイトでも何度か書いてきたが、本文に標準ライセンスの全文を含めつつ前に条項を足すという形は検出器を素通りするので特に見つけにくい。LICENSE は先頭から読むしかない。
treg を導入するかの判断材料
向いている場面
・単発のリサーチのために月額サブスクを買いたくない場合。これが treg の存在理由そのもので、1コール単位の課金が成立するならそのまま効く
・チームのAPIキーをメンバーの手元に配らずにエージェントへ使わせたい場合。資格情報はサーバー側に置いたままになる
・MCPサーバーを足しすぎて文脈が重い場合。設計の参考として読む価値がある。カタログをデータ側に置く発想はそのまま自分のサーバーに応用できる
向いていない場面
・顧客に出す製品へ組み込む用途。追加条項で要許諾になる
・外部サービスへの送信が制限された環境。ホスト版は treg.to への通信が前提で、本記事の環境でも遮断されて動かせなかった
・自前レジストリを PyPI 版で立てたい場合。配布版には検索まわりの実装が入っていないため、クローンからの運用が前提になりそうだ（ただし未検証）
何を代替するかは「ツールごとのMCPサーバーを1本ずつ足していく運用」だ。Semrush のMCP、Apollo のMCP、スクレイピングのMCP……と並べれば、アカウントもトークンも人数分増える。treg はそれを1つのベースURLと1つのトークンに畳む。代償として、呼び出しの経路に treg が1枚挟まることと、ライセンスの制約を受け入れることになる。
計測していて感心したのは、設計の主張とコードが揃っていたことだった。「カタログはデータ」と書いてあれば本当に13ツールで、「CLIはサーバー依存を引かない」と契約に書いてあれば本当に83MBで入る。90,347行に対して契約15本が無傷というのは、ドキュメントの美文より強い証拠になる。
一方で、ネットワーク断でトレースバックが出ること、配布版とリポジトリが同じ番号で中身が違うこと、GitHub のバッジが実際の条件を表していないこと——このあたりは使う前に知っておくと損しない類の話だ。本記事で測れたのはそこまでで、肝心のカタログの中身と値段は未検証のまま残っている。
参照ソース
・superdesigndev/treg（GitHub） — 本記事の計測対象。star 4,600
・LICENSE（追加条項の原文） — ホスティング制限とコントリビューター条項の出典
・src/treg/mcp.py — 「The catalog is data」の設計説明
・tools-registry（PyPI） — 配布パッケージ 0.22.0
計測値は data/measurements/runs/2026-10-07-treg-agent-tool-catalog.json に記録した。環境は Ubuntu 24.04 / x86_64 / Python 3.12.3。treg.to はこの環境から到達できないため、カタログ検索・課金・実際のツール呼び出し・自前レジストリの起動はいずれも未検証。
