TUUI：把 MCP 伺服器與多家 LLM API 收進同一個桌面客戶端
A desktop MCP client designed as a tool unitary utility integration, accelerating AI adoption through the Model Context Protocol (MCP) and enabling cross-vendor LLM API orchestration.
秒懂
- 它是什麼？
- TUUI 是一個以 TypeScript 與 Vue 3 寫成的桌面 MCP 客戶端，主打免帳號、跨供應商 LLM 設定與 MCP 伺服器探索。它的價值在於把協定層的瑣事集中到一個 GUI，代價是你得接受它自帶的設定檔與 localStorage 儲存模型。
- 適合誰用？
- 如果你要在本機把多個 MCP 伺服器與多家 LLM 端點放在同一個介面裡試用，而且不想註冊任何帳號，TUUI 的設定模型直接對應到 llm.json 與 mcp.json 兩個檔案，值得下載來驗證。若你的工作流程圍繞 IDE 的 Vibe Coding，或需要 Roots 這類用戶端能力，它現階段不適合，README 的支援表把 Roots 標為未實作。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 125 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
TUUI 想解決的是協定設定的摩擦，不是模型能力
MCP 的生態在過去一年長出大量伺服器，但每個伺服器的啟動方式不同：有的走 npx，有的走 uvx，有的要 Docker。把這些伺服器接進一個能呼叫工具的 LLM，通常要自己寫一段膠水程式，還要處理工具回傳值的格式。TUUI 把這件事收斂成一個桌面應用：你填好 LLM 端點，填好 MCP 伺服器設定，剩下的工具呼叫與對話流程由應用處理。
它的目標讀者寫得相當明確。README 開頭列出四個標籤：Zero accounts、Full control、Open source、Download and Run。這四點合起來描述的是一種特定需求：不想把 API key 交給第三方託管服務，不想為了試一個 MCP 伺服器去註冊帳號，而且希望設定檔留在自己機器上。專案本身也承認這是一場實驗，README 寫道這是「a bold experiment in creating a complete project using AI」，並提到專案內許多元件是從原型專案直接轉換或由 AI 生成。這句話對評估的人有意義：它解釋了為什麼專案強調嚴格的語法檢查與命名慣例，也提示你閱讀程式碼時會遇到什麼樣的風格。
三層設定：llm.json、mcp.json 與 localStorage
TUUI 的架構可以從設定檔的流向看出來。應用啟動時讀取內建的預設設定，位置在 src/main/assets/config/ 底下，其中 llm.json 管 LLM 端點，mcp.json 管 MCP 伺服器，startup.json 管啟動畫面的新聞內容，popup.json 管啟動時的提示。這些檔案在打包後的版本裡會落在 resources/assets/config/ 底下，也就是說你可以直接改動已發行版本的預設值，不必重新編譯。
一旦你在應用內修改或匯入設定，README 說明這些變更預設會存進 localStorage。這個設計決定了兩件事。第一，設定是跟著使用者設定檔走，不是跟著安裝目錄走，換機器不會自動帶過去。第二，要清掉所有設定，README 給的路徑是從 Tray Menu 選擇對應項目，而不是去刪檔案。對於需要在多台機器上維持一致設定的團隊，這代表你得自己處理設定匯出與匯入，專案沒有提供集中式的設定來源。
LLM 設定的型別定義放在 src/preload/llm.d.ts，這是判斷欄位語意時比 README 範例更可靠的地方。
LLM 端點設定：單一物件或陣列，靠 OpenAI 相容路徑切換供應商
TUUI 的跨供應商能力建立在一個務實的假設上：多數供應商都提供 OpenAI 相容的 chat completions 端點，差別只在 base url、path 與 model 名稱。README 給的 Qwen 範例把這件事拆得很清楚：url 指向 dashscope.aliyuncs.com/compatible-mode，path 是 /v1/chat/completions，model 是 qwen-turbo，modelList 列出 qwen-turbo、qwen-plus、qwen-max 三個可切換的選項，最後用 mcp: true 表示這個端點要參與 MCP 工具呼叫。
設定檔接受單一 JSON 物件，也接受 JSON 陣列。陣列形式讓你在同一個應用裡並存多家供應商，README 的範例就把 Openrouter 代理與 DeepInfra 放在同一個陣列裡。值得注意的是 Openrouter 那筆設定多了一個 urlList 欄位，列出 api3.aiql.com 與 openrouter.ai/api 兩個位址，而 DeepInfra 那筆的 path 是 /v1/openai/chat/completions，跟 Qwen 的 /v1/chat/completions 不同。這說明 path 是可自訂的，不是寫死的。
這裡有一個容易被忽略的前提。README 在 Core Requirements 段落明白寫出，要使用 MCP 相關功能，你的 LLM 後端必須支援 tool 或 function calling。一個只會純文字補全的端點，就算設定填對，也無法驅動 MCP 工具。apiKey 欄位在範例裡是空字串，實際使用時要自己填。
MCP 支援矩陣：伺服器端三項齊備，用戶端只缺 Roots
README 用一張表列出 MCP 功能支援狀態，這張表比任何宣傳文字都誠實。伺服器端三項 Tools、Prompts、Resources 都標為已完成。用戶端兩項 Sampling 與 Elicitation 也已完成。Registry 類的 Discovery 已完成，README 說明它提供 MCP 註冊表上的即時伺服器探索。Extension 類的 MCPB 也已完成，並註明 MCP Bundles（.mcpb）是原本 Desktop Extensions（.dxt）的新名稱。
唯一未實作的是用戶端的 Roots，狀態欄是空心方框。README 對這項的說明值得完整引用其意思：Roots 通常只用於 Vibe Coding 的 IDE，一般可以透過伺服器環境變數來設定。這個理由說得通，但也等於承認 TUUI 的定位不是 IDE 的替代品。如果你的工作流程需要用戶端主動向伺服器宣告可存取的檔案根目錄，這個缺口會直接擋住你。
Discovery 與 MCPB 的存在說明專案在追新規格。MCPB 是相對新的封裝格式，把它納入支援代表 TUUI 想當安裝入口，而不只是連線工具。這對想試用社群打包好的伺服器的人有實際幫助。
執行前置需求：Node.js、Python 與 UV、Docker 各對應一類伺服器
TUUI 本身是下載即用的桌面應用，但 MCP 伺服器不是。README 把前置需求按伺服器類型分開列：NPX 或 NODE 類的伺服器需要安裝 Node.js，UV 或 UVX 類的需要 Python 與 UV 函式庫，Docker 類的需要 DockerHub。這意味著應用能不能跑起來，取決於你要接的伺服器生態，而不是應用本身。
macOS 與 Linux 使用者多一項工作。README 明確寫出這兩個系統要修改預設的 MCP 設定，例如調整 CLI 路徑或權限，並指向文件中的 MCP Server Issue 段落。這是常見的桌面應用痛點：GUI 應用繼承的 PATH 往往跟終端機不同，npx 或 uvx 的路徑找不到就會連線失敗。
開發者路線的文件放在 docs/src/en/installation-and-build/getting-started.md 與對應的繁體中文版本，README 也提到專案設有 lint 工具，並要求後續開發者用它檢查與自動修正語法問題。這是專案對 AI 生成程式碼的因應方式，對貢獻者來說是一道必須遵守的門檻。
限制與不適用的場合
第一個限制是儲存模型。設定存在 localStorage，清除的入口在 Tray Menu 而不是檔案系統。對個人試用沒問題，對需要在多台機器或團隊成員之間同步 LLM 端點與 MCP 伺服器清單的情境，你得自己維護一份外部設定並手動匯入。專案沒有描述任何集中設定或版本控制整合。
第二個限制是 Roots 缺席，前面已說明。第三個限制與專案的自我定位有關。README 說這是「an LLM chat desktop application based on MCP」，本質是聊天應用，不是自動化執行環境。它列出 Automated application testing Support 作為亮點之一，但沒有在 README 中說明這套測試如何運作、涵蓋哪些範圍。要評估測試能力，只能去看程式碼與文件，README 本身不足以判斷。
最後，專案的 AI 生成背景是一個需要自行驗證的變數。README 說元件是從原型專案轉換或生成，並因此採用嚴格語法檢查。這不必然代表品質有問題，但代表你在採用前應該實際跑過你要用的那條路徑，而不是只看功能表。
與命令列 MCP Inspector 的差異
評估 MCP 伺服器時，官方生態裡常見的工具是 MCP Inspector，它以命令列方式啟動，開一個瀏覽器介面讓你逐項檢視伺服器暴露的 Tools、Prompts 與 Resources，並手動觸發呼叫。它的長處是貼近協定本身：你看到的是原始請求和回應，除錯時不會被中間層遮蔽。
TUUI 走的是相反方向。它把 MCP 伺服器接進一個帶對話介面的桌面應用，工具呼叫發生在自然語言對話流程裡，由 LLM 決定何時呼叫哪個工具。這對「這個伺服器在真實對話中好不好用」這個問題更有代表性，因為它測的是模型能否正確選擇工具、參數是否填對、回傳值能否被消化。代價是你失去逐項手動觸發的控制權，也比較難分辨失敗是伺服器的問題還是模型的問題。
實務上兩者不衝突。用 Inspector 確認伺服器本身行為正確，再用 TUUI 觀察它在對話中的表現，是比較省時間的順序。TUUI 的 Discovery 功能讓你能從 MCP 註冊表找到伺服器，這是 Inspector 沒有的入口。
授權、維護與升級成本
專案採用 Apache-2.0，這是一個寬鬆授權，允許修改與再散布，並包含專利授權條款。對企業內部使用而言，這個授權的相容性通常不是問題，但如果你要把 TUUI 打包進自己的產品，仍需自行確認 Apache-2.0 的標示與 NOTICE 要求，這部分請洽法務，本文不提供法律意見。
維護節奏可以從版本紀錄看出輪廓。v1.5.0-beta 在 2026-03-07 發布，v1.5.0 在隔天 2026-03-08 轉正，v1.5.1 則在 2026-05-14 發布，同日稍早倉庫也有推送。這是一個有在動的專案，但版本間隔不算密集，從 1.5.0 到 1.5.1 相隔約兩個月。
升級成本的主要來源是設定格式。llm.json 的欄位型別定義在 src/preload/llm.d.ts，當專案新增欄位時，你手動維護的設定可能需要跟著調整。由於使用者設定存在 localStorage，應用升級不會覆蓋你的設定，但也意味著新版本的預設值不會自動套用到你既有的設定上。每次升級後值得做的一件事，是比對 resources/assets/config/ 底下的預設檔案與你自己的設定差異。
編輯結論
如果你要在本機把多個 MCP 伺服器與多家 LLM 端點放在同一個介面裡試用，而且不想註冊任何帳號，TUUI 的設定模型直接對應到 llm.json 與 mcp.json 兩個檔案，值得下載來驗證。若你的工作流程圍繞 IDE 的 Vibe Coding，或需要 Roots 這類用戶端能力，它現階段不適合，README 的支援表把 Roots 標為未實作。採用前先確認三件事：你的 LLM 後端是否支援 tool calling、你的 MCP 伺服器是 NPX、UV 或 Docker 哪一種執行方式、以及在 macOS 或 Linux 上是否已依 MCP Server Issue 文件調整 CLI 路徑與權限。
社群筆記