TUUI: MCP サーバーと LLM をローカルで束ねるデスクトップクライアントの実像

TUUI が埋めようとしている穴は API キー管理ではなく接続の試行錯誤

MCP サーバーを試すとき、多くの人は設定ファイルを手で書き、CLI から起動し、ログを眺める。TUUI はこの往復をデスクトップアプリの画面に置き換える。README は自らを「LLM chat desktop application based on MCP」と説明しており、対象は MCP の Tools、Prompts、Resources を GUI から触りたい開発者である。加えて「Zero accounts」「Full control」を掲げ、アカウント登録なしで各自の API キーを持ち込む形を取る。つまりホスティング型のチャットサービスではなく、ローカルに置いたクライアントという位置づけだ。README には「creating a complete project using AI」という記述もあり、多くのコンポーネントがプロトタイプから AI によって変換または生成されたと明言されている。この点は後述する保守コストに直結する。

llm.json と mcp.json がすべての起点になる

設定の実体は JSON ファイルである。README の表によれば、LLM の既定チャットボット設定は src/main/assets/config/llm.json、MCP サーバーの既定設定は src/main/assets/config/mcp.json、起動画面は startup.json、ポップアップは popup.json に置かれる。型定義は src/preload/llm.d.ts にあり、ここを見ないと書けるキーが分からない。LLM 側の設定は 1 件のオブジェクトでも配列でも受け付ける。README の Qwen の例では name、apiKey、url、path、model、modelList、maxTokensValue、mcp というキーが並び、path に /v1/chat/completions を指定する。配列形式の例では OpenRouter 経由のものと DeepInfra のものが 1 つのファイルに同居し、urlList で複数のエンドポイントを候補として持てる。ベンダーを切り替えるたびにアプリを入れ替えるのではなく、この配列を編集するのが TUUI の基本操作になる。変更やインポートした設定は既定で localStorage に保存され、Tray Menu から全設定を消せる。

MCP のどこまでを実装し、どこを切っているか

README の対応表は率直で、Server 側の Tools、Prompts、Resources がいずれも対応済み、Client 側では Sampling と Elicitation が対応済みとされている。Registry 経由の Discovery も対応し、MCP レジストリ上のサーバーをリアルタイムに発見できると説明されている。MCPB も対応し、これは以前 Desktop Extensions と呼ばれていた .dxt の新しい名称だと注記されている。一方で Roots は未対応で、理由として「generally only used for the Vibe Coding IDE and can typically be configured through server environment variables」と述べられている。Roots はクライアントがサーバーに作業ディレクトリの範囲を伝える仕組みであり、これを環境変数で代替するという判断は、ファイルシステム境界をアプリ側で管理しないという設計方針の表明でもある。サーバーに渡すパスの制御を厳密にしたい用途では、この割り切りが効いてくる。

動かす前に揃えるもの: Node.js、Python と UV、Docker

TUUI 本体をインストールしても、MCP サーバーは別のランタイムで動く。README の Core Requirements はこれを明示している。ツール呼び出しに対応した LLM バックエンドが前提で、例として ChatGPT、Claude、Qwen、セルフホストが挙げられている。NPX や NODE ベースのサーバーには Node.js、UV や UVX ベースのサーバーには Python と UV、Docker ベースのサーバーには DockerHub が必要と書かれている。macOS と Linux では既定の MCP 設定を修正する必要があり、CLI のパスや権限の調整が求められる。README はこの点を MCP Server Issue のドキュメントを参照するよう案内している。つまり「ダウンロードして実行」はアプリの起動までを指し、MCP サーバーが動くところまでは環境構築の作業が残る。ここを軽く見積もると最初の接続でつまずく。

AI 生成を前提としたリポジトリ運用という制約

このプロジェクトは AI で作られた実験でもあると README 自身が述べ、その品質と安全性への配慮から「strict syntax checks and naming conventions」を採用していると説明している。開発に加わる場合は用意された lint ツールで構文の問題を検査し自動修正することが求められる。言い換えると、コードの一貫性は静的検査と命名規則で担保する方針であり、貢献や改修の入口にこの検査が立ちはだかる。自分でフォークして手を入れる場合、この規約に沿わない書き方は弾かれる前提で考える必要がある。リリースは v1.5.0 が 2026-03-07 のベータを経て 2026-03-08、v1.5.1 が 2026-05-14 と、比較的短い間隔で版を重ねている。ただし版数の多さは機能の成熟を意味しない。設定ファイルの形式が版をまたいで安定しているかは、リリースノート側で確認するしかない。

MCP Inspector や CLI クライアントと何が違うのか

MCP サーバーの検証だけが目的なら、公式の MCP Inspector や CLI ベースのクライアントで足りる場面が多い。これらはサーバーとのやり取りを直接叩いて入出力を確認する道具で、チャットの履歴管理や複数 LLM の切り替えは範囲外だ。TUUI の発想は逆で、チャットを主画面に置き、その会話の中で MCP の Tools、Prompts、Resources を呼ぶ。DeepInfra と OpenRouter を同じ llm.json に並べてモデルだけ差し替える、といった使い方が README の例から読み取れる。評価用のトピックとして llm-eval が挙がっている点も、単なる接続確認ではなくモデル比較を想定していることの表れだ。ただし Roots が未対応である以上、ワークスペースをまたぐファイル操作の検証は CLI 側に戻ることになる。用途によって道具を分けるのが現実的である。

向く人、向かない人、最初に確かめる 3 点

ライセンスは Apache-2.0 で、リポジトリの LICENSE に従う。派生物の扱いや表記義務の解釈はここでは扱わない。保守の観点では、設定が localStorage に保存される設計のため、マシンをまたいだ設定の共有や、複数人での同一構成の再現には向かない。Tray Menu から設定を消せることは、裏を返せば消えた設定を戻す手段を別に持っておく必要があるということだ。導入前に確かめるべきは 3 点ある。1 つ目は resources/assets/config/llm.json と mcp.json が自分の環境でどう解決されるか。2 つ目は使いたい MCP サーバーが Node.js、UV、Docker のどれを要求するか。3 つ目は Roots に依存しない範囲で目的が完結するか。この 3 点が噛み合うなら、API キーを手元に置いたまま複数ベンダーと MCP サーバーを 1 画面で扱う構成は成立する。噛み合わないなら、設定をコードとして管理できる CLI 側のツールにとどめておくほうが後戻りが少ない。

編集部の結論

TUUI が向くのは、複数ベンダーの API キーを自分で管理しつつ、MCP サーバーの接続確認やプロンプト・リソースの挙動を GUI で試したい開発者だ。逆に、チーム共有の設定管理や監査ログ、Roots を使ったワークスペース制御を前提とする使い方には向かない。導入前に確認すべきは resources/assets/config/llm.json と mcp.json が自分の環境でどう解決されるか、そして macOS や Linux で CLI パスと権限の調整が必要になる点である。

公式情報源

1. AI-QL/tuui on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases