Witsy: A Desktop Client That Puts MCP Servers Behind Any Chat Model

The gap Witsy targets: MCP servers without an Anthropic account

The Model Context Protocol gives a model a standard way to call external tools, but the clients that shipped early were tied to one vendor's stack. Witsy's README makes the claim directly: it is a universal MCP client, and the repository description calls it a "desktop AI assistant / universal MCP client." The audience is therefore narrow and specific. It is for someone who has already collected API keys from two or three providers, or who runs Ollama locally, and who wants to attach MCP servers to whichever model they happen to be using that day. It is not aimed at teams building an agent runtime, and it is not a library you import. The supported-provider table spans chat (OpenAI, Anthropic, Google, xAI, Meta, Ollama, LM Studio, MistralAI, DeepSeek, OpenRouter, Groq, Cerebras, Azure OpenAI, plus anything speaking the OpenAI API standard), image and video creation, text-to-speech, speech-to-text, search engines and embeddings. That breadth is the product. If you only ever use one provider, most of the surface area is dead weight.

What the architecture implies: Electron, Vue, and a BYOK key store

The topics list names electron-app, electronjs, vuejs and vuejs3, and the primary language is TypeScript. So the shape is a packaged desktop binary wrapping a web UI, built with npm and started with npm start during development. The BYOK model is the second structural fact: the README states plainly that you need API keys for the providers you want to use, or Ollama for local models. There is no proxy tier described, no account, no server-side component in the material given. Keys live in the app's settings, which is what makes a desktop client viable here and also what makes it a poor fit for a shared machine. On the MCP side, the README lists Anthropic MCP server support as a feature and Smithery.ai as the MCP repository, meaning server discovery is wired to one registry rather than a generic URL list, at least as documented. The rest of the feature list (scratchpad, prompt anywhere, AI commands on highlighted text, experts, long-term memory plugin, read-aloud, RAG over local files, dictation, voice mode, Anthropic Computer Use, local conversation history, PDF export) describes a client that has accumulated surfaces rather than one that does a single thing. That is a maintenance observation, not a criticism: every one of those surfaces is a place where a provider API change lands.

Getting it running: npm ci, npm start, or the cask

Two install paths are documented. Binaries come from the releases page, and on macOS the README gives one command: brew install --cask witsy. To build from source, the README shows exactly two lines, npm ci followed by npm start. After that, keys go into settings. The README links the key pages for OpenAI, Anthropic, Google, xAI, Meta, MistralAI, DeepSeek, OpenRouter, Groq and Cerebras, and notes that Ollama requires installing Ollama and downloading models separately. Optional capabilities each need their own credential: text-to-speech via OpenAI, Fal.ai, Fireworks.ai, Groq or Speechmatics, and internet search via a Tavily API key. The RAG path is the one place the README gives a click-level walkthrough, and it is worth quoting the shape rather than the words: you click the database icon left of the prompt, choose Manage, create a document repository, then add documents with the + button. Embeddings come from OpenAI (key required) or Ollama (embedding model required). Note that the supplied README is truncated inside that last sentence, so the exact steps for attaching a repository to a chat are not fully documented in the material I have.

Where it breaks down: keys on disk, one registry, and a truncated RAG doc

The clearest limitation is inherent to BYOK desktop software. The app holds provider credentials locally, and the README does not describe any encryption, OS keychain integration or scoping. That is not unusual for this class of tool, but it means Witsy is a personal-machine application. Put it on a shared workstation and every key in settings is readable by whoever else logs in. The second limitation is scope of MCP discovery. The table names Smithery.ai as the MCP repository. If your servers live in a private registry or you want to point the client at a local stdio server you built yourself, the README does not describe that path, so treat it as unverified rather than supported. Third, the RAG documentation is incomplete in the material provided, which matters because RAG is the feature with the most moving parts: an embedding provider, a repository, and per-chat attachment. Fourth, the wrong-tool case is worth stating plainly. Witsy is a GUI. If you need an MCP client that runs headless in a pipeline, or that other programs can script, a desktop Electron app is the wrong shape regardless of how many providers it supports.

How it differs from a single-vendor MCP client

The obvious comparison is a vendor-native client, for example Anthropic's own desktop tooling, which pairs MCP servers with Claude models and nothing else. The difference in approach is not cosmetic. A vendor client can assume one tool-calling format, one authentication scheme and one streaming protocol, which makes the integration tight and the failure modes few. Witsy inverts that: it takes the MCP server side as a fixed interface and normalises many provider APIs behind it, which is why the README can claim MCP servers run with "virtually any LLM." The cost of that inversion is visible in the provider table itself. Speech-to-text alone lists OpenAI Whisper, fal.ai, Fireworks.ai, Gladia, Groq, nVidia, Speechmatics, Local Whisper and Soniox, with a note about realtime versus async. Each of those is a separate integration to keep working. So the trade is breadth of model choice against depth of any single integration. If you are committed to one provider, the vendor client is the smaller, tighter tool. If your reason for using MCP is to avoid that commitment, Witsy is solving your problem and the vendor client is not.

Maintenance, releases, and what AGPL-3.0 changes

The release cadence in the material is three versions in roughly two months: v3.5.0 on 2026-01-30, v3.5.1 on 2026-02-21, v3.5.2 on 2026-03-04, with the last push to main on 2026-04-23. Patch-level releases at that spacing suggest active upkeep rather than a frozen project, though I cannot tell from this material what any given release contained, so do not read the version numbers as a stability guarantee. The practical upgrade cost for a desktop app is low: replace the binary, or brew upgrade the cask, and your settings persist. Building from source means tracking npm ci against a moving lockfile. The licence is AGPL-3.0, which is the part worth pausing on. AGPL's network clause is the distinguishing feature relative to GPL, and it is the reason some companies keep AGPL software off internal networks entirely. Using the app yourself is one thing. Forking it, modifying it, and exposing it to users over a network is where the obligation attaches. I am not a lawyer and this is not legal advice; if Witsy would sit behind a company network or be redistributed, get the licence reviewed by someone who is.

Editorial conclusion

Adopt Witsy if you already have API keys or a local Ollama install and you want to drive MCP servers from a desktop UI without writing your own client, and if AGPL-3.0 is acceptable for how you plan to use it. Do not adopt it if you need a headless, scriptable agent that runs in CI, or if you cannot accept that a desktop app holds plaintext provider keys. Before committing, verify the MCP repository path you actually need (Smithery.ai is the only one named in the README) and confirm that the RAG flow works against your embedding provider, since the README's walkthrough for document repositories is cut off mid-sentence.

Official sources

1. Issues
2. Kochava-Studios/witsy on GitHub
3. License: AGPL-3.0
4. README
5. Releases