TUUI : un client MCP de bureau pour orchestrer plusieurs fournisseurs de LLM

Le problème visé : tester des serveurs MCP sans chaîne d'outils imposée

Le README présente TUUI comme un client MCP de bureau et un banc d'essai local pour modèles. La formulation est explicite : il s'agit essentiellement d'une application de chat LLM basée sur MCP. Le public visé n'est donc pas l'utilisateur final qui veut discuter avec un assistant, mais la personne qui écrit ou branche des serveurs MCP et doit vérifier leur comportement. Un serveur MCP expose des Tools, des Prompts et des Resources ; encore faut-il un hôte capable de les appeler et d'afficher ce qui revient. TUUI se positionne comme cet hôte, avec une promesse de contrôle local : aucun compte, aucune dépendance à un service hébergé, un binaire téléchargé depuis la page Releases. Le README insiste sur l'orchestration de plusieurs API de fournisseurs via une configuration dynamique. Concrètement, cela signifie qu'un même client peut pointer vers Qwen, OpenRouter, DeepInfra ou une instance auto-hébergée, à condition que le backend accepte le tool calling. C'est une contrainte réelle et non un détail : un modèle sans function calling rend la partie MCP inopérante.

Ce que la matrice de fonctionnalités dit vraiment

Le README publie un tableau des fonctionnalités MCP avec un statut par ligne. Côté serveur, Tools, Prompts et Resources sont marqués comme pris en charge. Côté client, Sampling et Elicitation le sont aussi. La découverte via le registre MCP est indiquée comme opérationnelle, avec une découverte en temps réel des serveurs. Les MCP Bundles, anciennement Desktop Extensions, sont également listés comme pris en charge. Une ligne manque : Roots, marquée d'un carré vide. Le README justifie ce choix en indiquant que Roots sert généralement aux IDE de Vibe Coding et peut être remplacé par des variables d'environnement du serveur. C'est un argument défendable, mais il faut le lire comme un arbitrage, pas comme une équivalence. Un serveur qui attend une racine de projet dynamique pour résoudre des chemins relatifs ne trouvera pas dans TUUI le mécanisme prévu par la spécification. La ligne MCPB mérite aussi attention : le README précise que MCPB est le nouveau nom de ce qui s'appelait Desktop Extensions (.dxt). Le sujet dxt figure d'ailleurs dans la liste des topics du dépôt, ce qui suggère une continuité de nomenclature plutôt qu'une fonctionnalité distincte.

Architecture visible : Vue 3, Vuetify, Pinia et un processus principal qui lit des fichiers

Le dépôt est en TypeScript. Les badges du README renvoient à Vue 3 et Vuetify pour l'interface, et le projet déclare une gestion d'état globale via le store Pinia. Le layout est décrit comme un gestionnaire de disposition basique, ce qui est une manière honnête de dire qu'il n'y a pas de moteur de mise en page sophistiqué. La partie qui compte pour un intégrateur se trouve ailleurs : les fichiers de configuration par défaut vivent sous src/main/assets/config/, avec llm.json pour les points de terminaison LLM, mcp.json pour les serveurs MCP, startup.json pour l'écran de démarrage et popup.json pour les invites. Les types complets de la configuration LLM sont déclarés dans src/preload/llm.d.ts. Le README indique que ces fichiers sont modifiables dans un paquet décomposé : par exemple, src/main/assets/config/llm.json se retrouve dans resources/assets/config/llm.json après construction. Toute modification ou import de configuration est ensuite stockée dans le localStorage. C'est un point de conception à retenir : le fichier livré sert de valeur par défaut, pas de source de vérité persistante après le premier lancement. Un utilisateur qui édite llm.json après avoir déjà lancé l'application peut ne rien voir changer tant qu'il n'a pas purgé l'état local.

Mise en route : le format llm.json et les prérequis d'exécution

Le README donne un modèle pour un seul chatbot, avec les clés name, apiKey, url, path, model, modelList, maxTokensValue et mcp. L'exemple Qwen pointe vers https://dashscope.aliyuncs.com/compatible-mode avec le chemin /v1/chat/completions et le modèle qwen-turbo. La clé mcp est un booléen qui active la couche MCP pour ce point de terminaison. Le même fichier accepte un tableau pour plusieurs chatbots, et l'exemple fourni montre un premier objet nommé Openrouter && Proxy avec une urlList contenant deux entrées, puis un second objet DeepInfra dont le chemin est /v1/openai/chat/completions, ce qui illustre la variabilité des chemins selon les fournisseurs. Les prérequis sont listés sans ambiguïté : un backend LLM compatible tool calling, Node.js pour les serveurs NPX ou NODE, Python et UV pour les serveurs UV ou UVX, DockerHub pour les serveurs Docker. Sur macOS et Linux, le README demande d'ajuster la configuration MCP par défaut, notamment les chemins CLI et les permissions, et renvoie à une section MCP Server Issue. C'est le point de friction le plus probable au premier lancement : les configurations MCP publiées supposent souvent un environnement Windows. Pour repartir de zéro, le README mentionne la purge de toutes les configurations depuis le Tray Menu.

Le développement piloté par IA, assumé mais coûteux à reprendre

Le README qualifie le projet d'expérience audacieuse de création d'un projet complet par IA, et précise que de nombreux composants ont été convertis ou générés depuis un prototype. Cette déclaration a une conséquence pratique énoncée dans le même paragraphe : le projet applique des vérifications syntaxiques strictes et des conventions de nommage, et toute contribution doit passer par les outils de linting configurés pour corriger automatiquement les problèmes. Autrement dit, la qualité du code repose sur l'outillage plutôt que sur une relecture humaine systématique. Pour un mainteneur qui reprend le dépôt, cela déplace le coût : la première tâche n'est pas de comprendre l'architecture, mais de faire tourner la chaîne de lint et de vérifier ce qu'elle accepte. Le README ne détaille pas la liste des règles ni le seuil de couverture. Un lecteur qui cherche à savoir si les tests automatisés couvrent réellement les chemins MCP ne trouvera pas la réponse dans le README, qui se contente de mentionner un support de tests automatisés parmi les points forts. Il faudra ouvrir le dépôt pour trancher.

Limites et cas où TUUI n'est pas le bon outil

Trois limites ressortent du matériel fourni. La première est l'absence de Roots, déjà évoquée : un serveur MCP qui s'appuie sur ce mécanisme pour découvrir la racine du projet devra être configuré autrement, par variables d'environnement, ce qui déplace la logique hors du client. La deuxième concerne la persistance : les configurations importées finissent dans le localStorage, et le README ne décrit ni export ni synchronisation entre machines. Reproduire un environnement sur un second poste implique de rejouer les imports. La troisième tient aux prérequis d'exécution. TUUI ne fournit pas de runtime pour les serveurs MCP : il faut Node.js, Python avec UV, ou Docker selon le serveur visé. Un poste sans ces briques ne fera rien démarrer, quelle que soit la qualité de la configuration. Enfin, le README ne documente pas de politique de compatibilité entre versions de l'application et versions de la spécification MCP. Avec une version 1.5.1 publiée en mai 2026 et une 1.5.0 en mars 2026, le rythme de publication est irrégulier, et rien n'indique comment les configurations existantes survivront à un changement de spécification.

Face à MCP Inspector et aux IDE agentiques

L'alternative la plus directe est MCP Inspector, l'outil de référence pour examiner un serveur MCP. La différence d'approche est nette : Inspector se concentre sur l'inspection d'un serveur, avec une interface minimale et un objectif de débogage. TUUI ajoute une couche de chat multi-fournisseurs par-dessus : on y configure plusieurs backends LLM, on bascule entre eux, et on observe comment le modèle choisit et appelle les outils. Ce n'est pas le même travail. Inspector répond à la question « ce serveur expose-t-il correctement ses Tools et ses Resources ». TUUI répond plutôt à « ce modèle, branché sur ce serveur, produit-il un comportement utile ». Un IDE agentique qui gère les Roots se situe sur un troisième axe : il intègre le contexte du projet et l'édition de fichiers, ce que TUUI ne revendique pas. Le choix dépend donc de ce qu'on cherche à valider. Pour un test de conformité de serveur, Inspector reste plus direct. Pour comparer le comportement de deux modèles sur le même serveur MCP, TUUI a un argument que les autres n'ont pas sous cette forme.

Licence Apache-2.0 et coût de maintenance

Le dépôt est publié sous Apache-2.0, licence permissive qui autorise l'usage commercial, la modification et la redistribution, avec obligation de conserver les mentions de copyright et le texte de licence, et une clause de brevets explicite. Le README ne signale aucune restriction supplémentaire, aucun CLA et aucune condition d'attribution au-delà de ce que la licence impose. Pour un usage interne en entreprise, cela ne pose pas de difficulté particulière. La question du coût de maintenance se lit dans les dates : la dernière poussée sur main est datée du 14 mai 2026, le même jour que la publication de la version 1.5.1, et la version précédente remonte à mars 2026. Le projet n'est pas archivé. Cela dit, le README ne décrit pas de politique de support à long terme ni d'engagement sur les branches. Un utilisateur qui épingle une version et modifie llm.json ou mcp.json dans resources/assets/config/ devra refaire ces modifications à chaque mise à jour du paquet, puisque le README précise que ces fichiers font partie du build. Le coût réel n'est donc pas la licence, mais la reprise des configurations à chaque montée de version, tant qu'aucun mécanisme d'export n'est documenté.

Conclusion éditoriale

TUUI convient à un développeur seul ou à une petite équipe qui veut un banc d'essai MCP local sans compte ni service hébergé, et qui accepte de configurer ses points de terminaison à la main dans llm.json. Il ne convient pas à qui cherche un IDE agentique complet avec gestion des Roots, ni à une organisation qui exige une intégration SSO ou un support éditeur contractuel. Avant d'adopter, vérifiez trois choses dans votre clone : que la matrice du README correspond bien à votre cas d'usage côté Roots, que votre backend LLM accepte le tool calling, et que le fichier mcp.json livré démarre avec vos chemins CLI sur macOS ou Linux.

Sources officielles

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