Dive: an open source MCP host for desktop, with Electron and Tauri builds
Dive is an open-source MCP Host Desktop Application that seamlessly integrates with any LLMs supporting function calling capabilities. ✨
At a glance
- What is it?
- Dive is a desktop MCP host from OpenAgentPlatform that connects any function-calling LLM to MCP servers over stdio or SSE. This review covers the install path, the dual Electron and Tauri architecture, and where the setup still asks a lot of the user.
- Who is it for?
- Adopt Dive if you want a graphical MCP host on Windows, macOS or Linux and you are willing to manage Python, Node.js and npx uvx yourself on macOS and Linux, or to use OAPHub.ai to avoid that. Skip it if you need a headless or server-side MCP client, or if you want MCP server authentication you can rely on, since the README calls that feature unstable.
- Can I use it commercially?
- Yes. MIT 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 61 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 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Dive solves, and who ends up using it
The Model Context Protocol defines how a model talks to external tools, but it does not define where those tools run or how a person configures them. Dive is the host side of that split. It is a desktop application that holds a chat interface, a set of LLM provider credentials, and a list of MCP servers, then routes tool calls between them. The README describes it as "an open-source MCP Host Desktop Application that seamlessly integrates with any LLMs supporting function calling capabilities".
The audience is narrower than the feature list suggests. If you are comfortable wiring MCP servers into a terminal client or a code editor, Dive's value is mostly the graphical layer: per-server enable and disable, per-tool toggles, multiple API keys, and a model switcher backed by model_settings.json. The people who get the most out of it are those running several MCP servers at once and wanting to see which tools each one exposes without editing JSON by hand. The topics attached to the repository include mcp-client, mcp-host and mcp-server, which reflects that it sits on both sides of the protocol at different times.
How the host talks to MCP servers: stdio, SSE and the two shells
The README states that MCP integration works "on both stdio and SSE mode". Those are two different transports with different failure modes. A stdio server is a child process the host spawns and speaks to over standard input and output, so it lives and dies with the app and inherits its environment. An SSE server is reached over a URL, so it can run elsewhere but adds a network hop and whatever authentication that endpoint requires. Dive supports both, which means the configuration surface has to cover local commands and remote endpoints in the same settings file.
The application itself ships in two architectures, and the repository layout shows them as separate trees: src-tauri/ with its own Cargo.toml, and electron/ with electron-builder.json and vite.config.electron.ts. The README calls this a "dual architecture" and recommends the Tauri build on Windows for its smaller installer, described as under 30MB, while calling the Electron build the traditional and fully stable option. The platform table is the part to read carefully: Tauri is marked available on Windows and Linux, Electron on all three, and macOS Tauri is marked as not yet available. On Linux the README recommends Electron, and on macOS only the Electron .dmg is offered.
There are also built-in local tools that do not need an MCP server at all: Fetch for web requests, File Manager for reading and writing files, and Bash for command execution. Bash in particular is a tool that executes commands on the machine, so the trust boundary is the same as running a shell script you did not write.
Installing Dive and running a first MCP server
There is no package manager install for the application itself. The README points at the releases page, and the download badge links to the latest release. On Windows you pick the Tauri installer or the Electron one. On macOS you download the .dmg Electron build. On Linux you pick the Tauri build or the Electron .AppImage, and Arch users have a third route through an AUR helper, which the README gives as:
paru -S dive-aiOn Ubuntu or Debian with the AppImage, the README notes you may need the --no-sandbox parameter or a system setting change, and that the file must be made executable:
chmod +xThe environment requirements differ by platform, and this is the step people skip. Windows downloads Python and Node.js automatically after launch. macOS and Linux do not: the README says you need to install Python and Node.js yourself, with npx uvx available. If those are missing, MCP servers that are launched as local commands will fail to start, and the failure will look like a server problem rather than a missing runtime.
Building from source is a separate path and the README documents it in BUILD.md. The contributing section gives the clone and dependency steps, then the development commands:
git clone https://github.com/YOUR_USERNAME/Dive.git
npm install
npm run devThe README gives cargo tauri dev as the Tauri equivalent of npm run dev. Note that npm install triggers a postinstall step running patch-package and electron-builder install-app-deps, so a source checkout is heavier than a binary download. For server configuration itself, the README defers to MCP_SETUP.md, which is the file to read before adding your first server.
The OAPHub shortcut and what it hides
The fastest documented path to a working MCP server does not involve local runtimes at all. The README describes signing up at OAPHub.ai, connecting Dive through one-click deep links or configuration files, and using managed servers with, in its words, "zero setup - no Python, Docker, or complex dependencies required". The .env.example file carries a VITE_OAP_TOKEN entry, which is the build-time hook for that integration.
This is a real trade-off rather than a free win. Managed servers remove the Python and Node.js prerequisite, which is the single largest source of setup friction on macOS and Linux. They also move the server process off your machine and behind an account. The README states that local MCP and LLM configurations remain fully supported and that OAP integration is additive, so nothing forces the managed route. But if your reason for choosing an open source MCP host is to keep tool execution local, the managed path is the opposite of that, and the documentation does not describe what runs where once a server is managed.
Where Dive gets in the way
MCP server authentication is the clearest weak point, and the README says so directly: the feature is "currently unstable and may require frequent re-authorization". If your servers sit behind OAuth or a token that expires, plan on re-authenticating regularly. For a desktop tool you open a few times a day this is an annoyance; for anything you want to leave running, it is a blocker.
The second constraint is the platform matrix. Tauri on macOS is listed as coming soon, so macOS users get the Electron build and its larger footprint whether or not they want it. On Linux the recommendation flips to Electron as well. If you specifically wanted the smaller Tauri binary, your platform choice decides whether you can have it.
The third is the runtime dependency. Dive is a host, not a runtime manager, so on macOS and Linux it assumes Python and Node.js with npx uvx are already on the machine. The README does not document what happens when a server's runtime is missing beyond the general setup instructions. There is also no documented headless or server mode, no CLI, and no HTTP API for driving the host from another program. If your MCP client needs to run in CI or on a remote box, this is the wrong tool, and a library-level MCP client is the right one.
How Dive differs from a terminal MCP client
The obvious alternative for the same job is a terminal or editor-embedded MCP client, where servers are declared in a JSON config file and the client is the tool you already have open. The difference is not capability, since both speak the same protocol over the same transports. It is where the configuration lives and who can see it. A terminal client keeps servers in one text file you edit and version. Dive puts them behind a UI with per-server and per-tool toggles, a model switcher, custom system prompts, chat history search, and an installer agent that the README describes as helping you install and configure MCP servers automatically.
That UI layer is the entire argument for Dive. It costs you a graphical application, an auto-update mechanism, and a settings format you did not choose. It buys you the ability to see what tools a server exposes and turn individual ones off without reading source. For someone running one server with three tools, the terminal client wins on every axis. For someone running five servers with overlapping tool names, the toggle list is the feature that matters. The README also lists 24 or more UI languages, which matters if the person configuring servers is not the person who wrote them.
Licence, maintenance and the cost of upgrading
Dive is MIT licensed, which is permissive: you can use, modify and redistribute it, including in commercial settings, provided the licence notice is preserved. That applies to the application code. It does not automatically cover MCP servers you connect to, which carry their own licences, and it does not cover the OAPHub managed service, which is a separate hosted product with its own terms. Nothing here is legal advice; read LICENSE and the terms of anything you connect.
On maintenance, the repository is not archived and the last push was on 2026-07-31. The release history shows v0.14.3 on 2026-07-30, v0.14.2 on 2026-03-24, and v0.14.1 on 2026-02-26, so the cadence over that window is a few releases a year rather than continuous churn. The README's own recent-updates note is dated 2026/02/26 and covers v0.14.0 and later, adding skills, slash commands and chat history search.
Upgrade cost is mostly on the configuration side. The README states that existing local MCP and LLM configurations remain fully supported and that OAP integration is additive, so the migration note in the README suggests settings survive the OAP-era releases. What the README does not document is a rollback path if an auto-update lands badly, and since the application checks for and installs updates on its own, that is worth knowing before you rely on a specific version. If you need version pinning, the release page is where you would hold a build.
Editorial conclusion
Adopt Dive if you want a graphical MCP host on Windows, macOS or Linux and you are willing to manage Python, Node.js and npx uvx yourself on macOS and Linux, or to use OAPHub.ai to avoid that. Skip it if you need a headless or server-side MCP client, or if you want MCP server authentication you can rely on, since the README calls that feature unstable. Before relying on it, verify that the release for your platform and architecture exists, check whether the Tauri build you want is listed as available for your OS, and read MCP_SETUP.md for the server configuration format.
Frequently asked questions
Is there an open source MCP Host available?
Yes. Dive is an open source MCP host desktop application from OpenAgentPlatform, licensed under MIT, and the README states it supports MCP integration over both stdio and SSE mode.
How do I download and install Dive?
The README points to the latest release on GitHub rather than a package manager. Windows users choose between the Tauri and Electron installers, macOS users download the Electron .dmg, and Linux users pick the Tauri build or the Electron .AppImage. Arch users can install dive-ai through an AUR helper.
Does Dive run MCP servers over stdio and SSE?
The README states that MCP integration works on both stdio and SSE mode. A stdio server is a local process the host launches, while an SSE server is reached over a URL.
Which platforms does Dive support?
The README's platform table lists Electron on Windows, macOS and Linux, and Tauri on Windows and Linux, with macOS Tauri marked as coming soon. On Linux the README recommends the Electron build.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/openagentplatform-dive)