TUUI: ein Desktop-MCP-Client mit lokaler LLM-Konfiguration

Welches Problem TUUI löst

Wer heute einen MCP-Server ausprobieren will, braucht dafür meist einen Host, der den Server startet, seine Werkzeuge an ein Modell weitergibt und die Antwort zurückführt. Fertige Chat-Anwendungen erledigen das, verlangen aber ein Konto und legen fest, welcher Modellanbieter verwendet wird. TUUI geht den anderen Weg: Die Anwendung läuft als Desktop-Programm, die Modell-Endpunkte trägt man selbst in eine Konfigurationsdatei ein, und die API-Schlüssel bleiben lokal. Das README nennt als Zielgruppe niemanden explizit, aber die Struktur der Konfiguration macht die Zielgruppe sichtbar. Wer mehrere Anbieter parallel betreiben will, legt ein JSON-Array an und wechselt zwischen OpenRouter, DeepInfra oder einem selbst gehosteten Endpunkt, ohne die Anwendung neu zu starten. Das ist ein Entwicklerwerkzeug, kein Endnutzerprodukt. Die vier Schlagworte im README, zero accounts, full control, open source, download and run, beschreiben genau diese Haltung: kein Anmeldeformular, kein Server des Anbieters in der Mitte, dafür die Pflicht, die eigene Umgebung selbst vorzubereiten.

Wie die Konfiguration aufgebaut ist

Die zentrale Datei ist src/main/assets/config/llm.json. Ein Eintrag enthält die Felder name, apiKey, url, path, model, modelList, maxTokensValue und mcp. Das Feld mcp ist ein Schalter: Steht er auf true, darf das Modell die Werkzeuge der verbundenen MCP-Server verwenden. Der Typ dieser Struktur liegt in src/preload/llm.d.ts, was bedeutet, dass die Konfiguration zur Build-Zeit geprüft wird und nicht erst beim Start der Anwendung. Das README zeigt zwei Formen: ein einzelnes Objekt für einen Chatbot oder ein Array für mehrere. Ein Beispiel für Qwen nutzt url https://dashscope.aliyuncs.com/compatible-mode mit path /v1/chat/completions, ein Beispiel für DeepInfra nutzt url https://api.deepinfra.com mit path /v1/openai/chat/completions. Der Pfad ist also nicht fest verdrahtet, sondern Teil der Konfiguration. Das erlaubt Endpunkte, die nur teilweise OpenAI-kompatibel sind. Für Anbieter mit mehreren Adressen gibt es zusätzlich urlList, wie im Beispiel Openrouter && Proxy mit den Einträgen https://api3.aiql.com und https://openrouter.ai/api. Die Konfiguration der MCP-Server selbst liegt in src/main/assets/config/mcp.json, und das README verweist für die Syntax auf die Serverliste des MCP-Projekts. Zwei weitere Dateien, startup.json und popup.json, steuern den Startbildschirm und die dort angezeigten Eingabeaufforderungen. Nach dem Import oder einer Änderung landen die Einstellungen im localStorage. Im gebauten Paket liegen die Standarddateien unter resources/assets/config/, etwa resources/assets/config/llm.json.

Was TUUI vom MCP-Protokoll abdeckt

Die README-Tabelle listet den Umsetzungsstand nach Server- und Client-Seite getrennt. Auf der Serverseite sind Tools, Prompts und Resources mit einem Haken versehen, also vollständig vorhanden. Auf der Client-Seite stehen Sampling und Elicitation auf erledigt, Roots dagegen nicht. Die Begründung im README ist knapp: Roots werde in der Regel nur für Vibe-Coding-IDEs gebraucht und lasse sich meist über Umgebungsvariablen des Servers konfigurieren. Das ist eine bewusste Auslassung, keine Lücke aus Nachlässigkeit, aber sie hat Folgen. Ein MCP-Server, der die Wurzelverzeichnisse des Clients erwartet, um darin zu arbeiten, wird sich hier nicht wie erwartet verhalten. Zwei weitere Punkte stehen außerhalb der Protokolltabelle. Discovery ist mit einem Haken versehen und bezieht sich auf die MCP-Registry, aus der TUUI Server in Echtzeit finden kann. MCPB ist ebenfalls abgehakt: MCP Bundles mit der Endung .mcpb, früher Desktop Extensions oder .dxt, lassen sich damit einbinden. Wer die Protokollversion prüfen will, die TUUI spricht, findet dazu im vorliegenden Material keine Angabe. Das ist ein Punkt, den man vor einem Einsatz selbst nachsehen muss.

Voraussetzungen, die vor dem ersten Start fehlen können

Das README nennt die Bedingungen für MCP-Funktionen in einer eigenen Liste, und diese Liste ist der praktisch wichtigste Teil der Dokumentation. Erstens braucht man ein LLM-Backend mit Unterstützung für Tool- oder Function-Calling. Ohne diese Eigenschaft bleibt mcp: true wirkungslos, weil das Modell die Werkzeugaufrufe nicht erzeugen kann. Zweitens hängt die Laufzeitumgebung vom Server ab: NPX- und Node-basierte Server verlangen eine Node.js-Installation, UV- und UVX-basierte Server verlangen Python und die UV-Bibliothek, Docker-basierte Server verlangen DockerHub. Drittens weist das README darauf hin, dass unter macOS und Linux die Standard-MCP-Konfiguration angepasst werden muss, etwa bei CLI-Pfaden oder Berechtigungen, und verweist dafür auf einen Abschnitt namens MCP Server Issue. Diese Hinweise sind ehrlich, aber sie verschieben einen guten Teil der Arbeit auf den Nutzer. Ein Server, der unter Windows ohne Änderung startet, kann unter Linux einen angepassten Pfad benötigen. Wer TUUI nur herunterlädt und einen MCP-Server aktiviert, ohne die passende Laufzeit installiert zu haben, bekommt keinen Hinweis auf eine fehlende Funktion, sondern schlicht einen Server, der nicht startet.

Installation und erste Konfiguration

Für die reine Nutzung verweist das README auf die Releases-Seite, auf der Builds für Windows, Linux und macOS liegen. Wer aus dem Quellcode bauen will, folgt dem Getting-Started-Dokument, das in einer englischen und einer chinesischen Fassung vorliegt. Nach dem Start importiert man die LLM-Konfiguration als JSON-Objekt oder als JSON-Array. Ein minimaler Eintrag für einen selbst gehosteten Endpunkt sieht so aus: name auf einen freien Namen setzen, apiKey auf den Schlüssel des Anbieters, url auf die Basisadresse, path auf den Pfad der Chat-Completions-Route, model auf das Standardmodell, modelList auf die auswählbaren Modelle und mcp auf true. Die Standarddateien lassen sich auch direkt im gebauten Paket bearbeiten, weil sie unter resources/assets/config/ liegen. Wer die Einstellungen vollständig zurücksetzen will, kann laut README alle Konfigurationen über das Tray-Menü löschen. Das ist der einzige im Material genannte Weg zum Zurücksetzen, und er ist grob: Er entfernt alles, nicht einzelne Einträge. Ein selektives Zurücksetzen einzelner Modelle oder Server ist aus der Beschreibung nicht ersichtlich.

Grenzen und Fälle, in denen TUUI das falsche Werkzeug ist

Die wichtigste Einschränkung steht im README selbst: Das Projekt wird als Experiment beschrieben, einen vollständigen Projektaufbau mit KI zu erstellen, und viele Komponenten seien direkt aus dem Prototyp übernommen oder daraus erzeugt worden. Daraus folgt eine strenge Syntaxprüfung und ein Namensschema, an das sich jeder weitere Beitrag halten muss. Für einen Nutzer bedeutet das zweierlei. Erstens ist die Codebasis möglicherweise ungleichmäßig, und zweitens ist jede Erweiterung an die vorhandenen Lint-Werkzeuge gebunden. Wer eigene Änderungen einbringen will, muss diese Werkzeuge einrichten, sonst scheitert der Beitrag an der Prüfung. Eine zweite Grenze betrifft die Konfigurationsablage. Die Einstellungen liegen im localStorage der Anwendung. Wer zwischen zwei Rechnern wechselt, muss die JSON-Dateien selbst mitnehmen. Es gibt keine Synchronisierung, und es gibt im Material auch keinen Hinweis auf Export- oder Importfunktionen jenseits der Dateien. Drittens ist TUUI kein Server. Es ist ein Client, der MCP-Server startet und mit einem Modell verbindet. Wer eine gehostete Schnittstelle für ein Team braucht, die zentral verwaltet wird, wird hier nicht fündig. Und wer einen Chat ohne eigene API-Schlüssel sucht, ebenfalls nicht.

Alternative: Claude Desktop und MCP-Inspector

Der naheliegende Vergleich ist Claude Desktop, das ebenfalls MCP-Server einbindet und ebenfalls eine JSON-Konfigurationsdatei verwendet. Der Unterschied liegt beim Modell. Claude Desktop spricht mit Claude, TUUI spricht mit allem, was sich über einen OpenAI-kompatiblen Pfad ansprechen lässt, und erlaubt mehrere Anbieter gleichzeitig in einem Array. Wer ohnehin nur Claude nutzt, gewinnt durch TUUI wenig. Der zweite Vergleich ist der MCP-Inspector, ein Werkzeug zum Debuggen von MCP-Servern. Er zeigt Werkzeugaufrufe und Antworten, führt aber keine Unterhaltung mit einem Modell, das selbst entscheidet, welches Werkzeug es aufruft. TUUI trennt sich von beiden durch die Kombination: mehrere Modell-Endpunkte, Discovery über die MCP-Registry, MCPB-Unterstützung und ein Modell, das die Werkzeuge tatsächlich verwendet. Wer nur einen Server auf korrekte Antworten prüfen will, ist mit dem Inspector schneller bedient, weil er keine Modellkonfiguration braucht.

Wartung, Lizenz und was vor dem Einsatz zu prüfen ist

Die letzten Veröffentlichungen liegen bei v1.5.1 vom 14. Mai 2026, davor v1.5.0 vom 8. März 2026 und eine Beta vom 7. März 2026. Zwischen den beiden stabilen Versionen liegen rund zwei Monate, und die Versionsnummern bewegen sich im Bereich der zweiten Stelle. Ein festes Versprechen für Update-Zyklen lässt sich daraus nicht ableiten, aber die Abstände sind kurz genug, dass man mit Änderungen an der Konfigurationsstruktur rechnen sollte. Das ist relevant, weil llm.json und llm.d.ts zusammenhängen: Ändert sich der Typ, müssen bestehende Konfigurationen möglicherweise angepasst werden. Die Lizenz ist Apache-2.0. Das erlaubt kommerzielle Nutzung und Änderungen, verlangt aber, dass der Lizenztext und Hinweise auf Änderungen mitgeführt werden. Wer TUUI weiterverbreitet, muss die Bedingungen der Lizenz einhalten. Eine rechtliche Bewertung ersetzt das nicht. Vor dem Einsatz sollte man drei Dinge prüfen: ob der gewählte LLM-Endpunkt Function Calling unterstützt, ob die Laufzeitumgebung für den jeweiligen MCP-Server installiert ist, und ob der Server Roots erwartet, denn dieser Teil des Protokolls fehlt in TUUI.

Redaktionelles Fazit

TUUI passt zu Entwicklern, die MCP-Server gegen mehrere LLM-Anbieter testen wollen, ohne ihre API-Schlüssel an einen Hosting-Dienst zu geben. Wer einen gehosteten Chat mit fertigen Integrationen sucht, ist hier falsch. Vor dem Einsatz sollte man prüfen, ob der gewählte LLM-Endpunkt Function Calling unterstützt und ob die lokale Node.js-, Python- oder Docker-Umgebung für den jeweiligen MCP-Server vorhanden ist.

Offizielle Quellen

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