TUUI is an Apache-2.0 Electron-style desktop chat client that speaks the Model Context Protocol and lets you point it at any OpenAI-compatible endpoint. The pitch is zero accounts and full local control. The catch is that the whole thing is an experiment in AI-generated code, and the README says so.

Can I use AI-QL/tuui commercially?

Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is AI-QL/tuui still maintained?

Yes. The repository last received commits 125 days ago.

What programming language is AI-QL/tuui written in?

Mainly TypeScript, according to GitHub's language statistics.

TUUI review: a local MCP client for cross-vendor LLM APIs

At a glance

What is it?: TUUI is an Apache-2.0 Electron-style desktop chat client that speaks the Model Context Protocol and lets you point it at any OpenAI-compatible endpoint. The pitch is zero accounts and full local control. The catch is that the whole thing is an experiment in AI-generated code, and the README says so.
Who is it for?: Adopt TUUI if you want a local desktop surface for MCP servers and you are comfortable editing llm.json and mcp.json by hand, or importing them through the UI and having them persist in localStorage. Do not adopt it if you need MCP Roots support, or if you expect a codebase whose history is fully human-authored: the README states that many components were converted or generated from a prototype by AI, which is why it enforces strict linting and naming conventions.
Can I use it commercially?: Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository last received commits 125 days ago.
What is it written in?: Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 10, 2026 · AI-QL/tuui

The problem TUUI is aimed at: MCP servers with nowhere to plug in

MCP servers are easy to write and awkward to try. A server exposes tools, prompts and resources over the protocol, but a server on its own does nothing visible. You need a host that connects to it, lists what it offers, and passes the model's tool calls back. Most people end up doing that inside a coding IDE or a vendor's own desktop app, which ties the experiment to one LLM provider. TUUI takes the other route. It is a desktop chat application that acts as the MCP host, and it treats the LLM backend as a swappable configuration entry rather than a fixed dependency. The README describes it as a tool unitary utility integration, which is marketing phrasing for a single window where you can add MCP servers and then choose which model drives them. The intended audience is narrow and identifiable: developers who already have an API key for an OpenAI-compatible endpoint, or a self-hosted model that supports tool calling, and who want to see an MCP server behave without signing up for anything. The badge row says zero accounts, full control, open source, download and run, and the releases page is the primary distribution channel for Windows, Linux and macOS builds.

What the MCP feature table actually promises, and what it leaves out

The README carries a status table, and it is the most useful page in the repository because it states what is missing. Tools, Prompts and Resources are marked complete on the server side. Sampling and Elicitation are marked complete on the client side, which means TUUI can handle a server asking the model for a completion and a server asking the user for input mid-call. Discovery is marked complete for the MCP registry, so the app can find servers in real time rather than requiring you to paste a command. MCPB support is listed under Extension, with a note that MCP Bundles (.mcpb) is the new name for what was previously Desktop Extensions (.dxt). One row is unchecked: Roots, which the README explains is generally only used for the Vibe Coding IDE and can typically be configured through server environment variables instead. That is a reasonable omission for a chat client and a real gap if your server relies on the client to declare filesystem roots. The honest reading is that TUUI covers the server-facing half of the protocol well and the client-facing half partially, with Roots deliberately skipped. If your workflow depends on Roots, this is not the host for it, and the README says as much rather than hiding it.

How configuration flows: llm.json, mcp.json, and localStorage

The mechanism is file-based and then browser-based. Two default config files ship inside the app: src/main/assets/config/llm.json for LLM endpoints and src/main/assets/config/mcp.json for MCP servers. The README points at src/preload/llm.d.ts as the place where the full config types live, which matters because the JSON schema is not documented in prose anywhere else in the supplied material. Each LLM entry carries a name, apiKey, url, path, model, a modelList array, maxTokensValue and an mcp boolean. The path field is what makes cross-vendor orchestration work: Qwen is configured with /v1/chat/completions against dashscope.aliyuncs.com/compatible-mode, while DeepInfra uses /v1/openai/chat/completions against api.deepinfra.com. The config accepts either a single object or an array, so one file can hold several providers and you switch between them in the UI. There is also a urlList field in the OpenRouter example, listing both a proxy host and the upstream API, which suggests failover or routing between them, though the README does not explain the selection rule. Two more config files exist for non-LLM content: startup.json for the news shown on the startup screen and popup.json for prompts. For a built release, the same paths appear under resources/assets/config/. The persistence detail that matters most: once you modify or import configurations, the README states they are stored in your localStorage by default, and a Tray Menu option clears all configurations. That is the whole storage model. API keys end up in the app's localStorage, not in an OS keychain, and the README does not claim otherwise.

Runtime prerequisites you have to satisfy before any server starts

TUUI does not bundle a runtime for the servers it launches. The Core Requirements section lists them explicitly. You need an LLM backend that supports tool or function calling, whether that is ChatGPT, Claude, Qwen or something self-hosted. For NPX or NODE-based servers you need Node.js installed. For UV or UVX-based servers you need Python plus the UV library. For Docker-based servers you need Docker. On macOS and Linux, the README says you must modify the default MCP configuration, adjusting CLI paths or permissions, and it points to the MCP Server Issue documentation for guidance. That last point is the practical friction most users will hit first. A server configured for a Windows path will not launch on Linux, and a permission problem on macOS will surface as a server that fails to start rather than a clear error. The README does not enumerate the specific edits, so treat the MCP Server Issue section as required reading before you file anything. The dependency chain is also worth naming plainly: installing TUUI installs a chat client, not an MCP environment. Everything a server needs to run is your responsibility.

The AI-generated codebase is a stated design constraint, not a footnote

The introduction says this repository represents a bold experiment in creating a complete project using AI, and that many components were directly converted or generated from the prototype project through AI. It then draws the operational conclusion: given considerations about the quality and safety of AI-generated content, the project employs strict syntax checks and naming conventions, and any further development should use the linting tools that are set up to check and fix syntax issues. This is unusually direct, and it changes how you should read the rest of the README. The linting requirement is not a style preference you can skip; it is the stated mechanism for keeping a partly generated codebase coherent. If you plan to contribute, expect the linter to reject code that would pass in a more permissive project. If you plan to fork, understand that you are inheriting that constraint along with the code. The README does not quantify how much of the codebase is AI-derived, so any claim about the proportion would be guesswork. What can be confirmed is the author's own framing and the mitigation they chose.

Where TUUI is the wrong tool

Three cases stand out. First, if your MCP server depends on Roots, TUUI will not serve it, because that row is unchecked and the README directs you to server environment variables instead. Second, if your threat model requires API keys in an OS keychain with per-application access control, the localStorage model is a mismatch, and no amount of configuration changes that. Third, if you want a library to embed rather than a desktop app to install, TUUI is the wrong shape entirely: it ships as platform builds from the releases page, and the developer path runs through docs/src/en/installation-and-build/getting-started.md rather than an npm package you import. There is also a subtler limitation in the config design. The mcp boolean on each LLM entry suggests MCP support is toggled per provider, but the README does not explain what happens when a model in modelList does not support tool calling, or how the app behaves when a server advertises a tool the selected model cannot invoke. Those failure modes are not documented in the supplied material, and I would not assume graceful handling. The multilingual support and Pinia store are listed as highlights but carry no detail about which languages or what state is persisted, so treat both as unverified until you check the source.

The alternative worth comparing: the official MCP Inspector

The most direct comparison is the MCP Inspector, which the topic list names alongside mcp-client and mcp-host. The difference in approach is the point. The Inspector is a debugging tool for a single server: you point it at one server, inspect its tools, prompts and resources, and call them manually. TUUI is a chat host: you configure several servers and several LLM providers at once, and the model decides which tools to call during a conversation. That makes TUUI better for evaluating whether a model can actually use a server in practice, and worse for isolating a server bug, because a failure could come from the server, the model's tool-calling behaviour, or the host. If you are writing an MCP server and something is broken, reach for the Inspector first. If you are trying to decide whether a given model plus a given server produces useful results, TUUI is the more honest test because it exercises the full loop. The two are complements, not substitutes, and the README's own topic list acknowledges that by tagging both mcp-inspector and mcp-client.

Licence, release cadence and what maintenance actually costs you

TUUI is Apache-2.0. That permits commercial use, modification and redistribution, and it includes an explicit patent grant, which matters if you embed the client in something you ship. It also carries attribution and notice requirements, and the licence text at LICENSE is the authority rather than anything here. I am not giving legal advice; if you redistribute a modified build, read the licence yourself. The release history gives a rough sense of cadence: v1.5.0-beta on 2026-03-07, v1.5.0 the next day, and v1.5.1 on 2026-05-14, with the last push to main on the same day as v1.5.1. That is a two-month gap between the 1.5.0 line and 1.5.1, which suggests maintenance is active but not high-frequency, and the repository is not archived. The upgrade cost is concentrated in the config files. Because llm.json and mcp.json live inside the app bundle and get copied into localStorage on import, a version bump that changes the config schema will not automatically migrate what you already stored. The README's own escape hatch is the Tray Menu option that clears all configurations, which means a schema change can cost you a re-entry of every API key and server definition. Back up your exported config before upgrading, and check src/preload/llm.d.ts after each release to see whether the type surface moved.

Editorial conclusion

Adopt TUUI if you want a local desktop surface for MCP servers and you are comfortable editing llm.json and mcp.json by hand, or importing them through the UI and having them persist in localStorage. Do not adopt it if you need MCP Roots support, or if you expect a codebase whose history is fully human-authored: the README states that many components were converted or generated from a prototype by AI, which is why it enforces strict linting and naming conventions. Before committing, verify three things in the repository: that src/preload/llm.d.ts covers every config key you intend to use, that your target MCP servers run under the Node, UV or Docker prerequisite you actually have installed, and that the macOS and Linux CLI path adjustments described in the MCP Server Issue documentation match your shell.

Official sources

Community notes