Dive: an MCP host desktop app with two runtimes and a cloud escape hatch
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 TypeScript desktop application that acts as an MCP host, connecting local or hosted MCP servers to any LLM with function calling. Its real distinguishing choices are a dual Electron and Tauri build and an optional managed-server path through OAPHub.
- Who is it for?
- Adopt Dive if you want a desktop MCP host that keeps local server configuration under your control and you are willing to install Python and Node.js yourself on macOS and Linux. Skip it if you need the Tauri build on macOS, since the README marks that combination as not yet available, or if you want a headless host for CI.
- 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 47 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
The gap Dive fills between an MCP server and a chat window
An MCP server on its own is a process that speaks a protocol. Something has to launch it, keep it alive, decide which of its tools are exposed to a model, and route the model's tool calls back. That something is an MCP host, and Dive is one, packaged as a desktop application rather than a CLI or a library. The README describes it as an "open-source MCP Host Desktop Application" that integrates with "any LLMs supporting function calling capabilities."
The target user is someone who already has, or wants, MCP servers and wants to drive them from a graphical client on their own machine. The README lists Windows, macOS and Linux support, 24 or more interface languages, and pre-configured built-in tools: Fetch for web requests, File Manager for reading and writing files, and Bash for command execution. Those built-ins matter because they mean the application is useful before you configure a single external server.
It is not a framework for building agents into your own software. There is no server SDK here and no headless mode described. If your goal is to embed MCP tool calling in a backend service, Dive is the wrong shape of project.
Two runtimes, three platforms, and one missing cell
The repository ships an Electron build and a Tauri build. The README calls this a "Dual Architecture" and describes the Tauri version as the modern one with a smaller installer, under 30MB on Windows. Electron is presented as the traditional, fully stable option. The development commands differ accordingly: npm run dev starts the Electron app, while cargo tauri dev starts the Tauri one, which is consistent with Tauri's Rust toolchain.
The platform table is where the trade-off becomes concrete. Windows has both builds. Linux has both builds, with Electron recommended and distributed as an AppImage. macOS has Electron only; the Tauri column is marked with a "coming soon" marker rather than a check. So the smaller installer and the newer runtime are unavailable to Mac users today, and the README does not give a date.
Linux carries its own friction. Ubuntu and Debian users may need to pass --no-sandbox or adjust system settings to allow the sandbox, and the AppImage needs chmod +x before it will run. Arch users have a third route: an AUR package installed through an AUR helper, with paru -S dive-ai given as the example. That is a distribution channel the project does not control, so its update cadence will not necessarily match the GitHub releases.
How a session actually flows from prompt to tool result
The mechanism, as far as the README and repository layout disclose it, is the standard MCP host loop. You configure servers, Dive starts them and enumerates their tools, you pick a model and an API key, and the model's function calls are dispatched to the matching tool. The README states that MCP integration works in both stdio and SSE mode, which covers locally spawned processes and servers reached over HTTP.
Control over what gets exposed is per tool. The feature list describes "Granular Tool Control" for enabling and disabling individual MCP tools, which is the difference between a host that hands a model everything a server offers and one where you can withhold, say, a write operation while keeping reads. Custom instructions are supported as system prompts, and the @ keyword in the chat input is extended to search file paths, so a prompt can reference a file without a separate picker.
Model configuration is file-based. The README names model_settings.json as the place where multiple API keys and model switching are handled. That is a plain configuration file rather than a database, which makes it easy to inspect and version, and equally easy to corrupt by hand. The README does not publish a schema for it, so the reliable source of truth is the application's own settings interface.
Since v0.14.0 the project also lists skills and slash commands, plus search over chat history. Chat drafts are saved automatically, and there is an auto-update mechanism that checks for and installs new versions.
Getting it running: installers, environments, and the OAPHub shortcut
Installation splits by platform in a way that affects how much work you do. On Windows, the README says Python and Node.js environments are downloaded automatically after launching, for both the Tauri and Electron builds. On macOS and Linux, you install Python and Node.js yourself, including npx and uvx. That asymmetry is the single biggest setup variable: a Windows user may reach a working MCP server without touching a terminal, while a Linux user is installing a Python toolchain first.
There are two documented paths to MCP servers. The local path is described in MCP_SETUP.md, which the README points to for detail. The managed path runs through OAPHub: sign up at oaphub.ai, connect Dive using one-click deep links or configuration files, and use servers hosted by that service. The README frames the benefit as avoiding Python, Docker and other dependencies locally. A migration note states that existing local MCP and LLM configurations remain fully supported and that OAP integration is additive.
There is also an MCP Server Installer Agent, described as an agent that helps install and configure MCP servers. The README does not explain what it does beyond that sentence, so treat it as an unverified convenience rather than a documented workflow.
For contributors, the path is npm install, then npm run dev or cargo tauri dev, with build instructions in BUILD.md. Running from source is the only way to inspect behaviour the README leaves unspecified.
Where Dive gets in the way
The most clearly stated weakness is MCP server authentication. The README marks it with a warning that the feature is "currently unstable and may require frequent re-authorization." For anyone pointing Dive at an authenticated remote server, that is a recurring interruption, not a one-time setup cost.
The built-in Bash and File Manager tools are a second consideration. They are on by default per the feature list, and they give a model command execution and file read/write on the machine running Dive. The README does not describe a sandbox around them. Granular tool control lets you disable MCP tools, but the material does not state whether the built-ins can be switched off the same way, so verify that in the settings UI before assuming you can.
Configuration is another soft spot. Multiple API keys and model switching live in model_settings.json with no published schema, which means hand-editing is guesswork and the application's UI is the safer editor. And the Tauri build is simply not an option on macOS, so Mac users who chose Dive for the smaller installer will not get it.
Finally, this is a desktop GUI. There is no documented headless mode, no server mode, no way to run it in CI. If your MCP tool calls need to happen inside a build pipeline or a backend service, a desktop host is the wrong layer.
How Dive differs from Claude Desktop and from writing your own host
The obvious comparison is Claude Desktop, which is also an MCP host on the desktop. The difference is model scope. Claude Desktop connects MCP servers to Anthropic's models. Dive positions itself as model-agnostic, listing ChatGPT, Anthropic, Ollama and OpenAI-compatible endpoints, with Ollama appearing in the repository topics alongside ollama-client and ollama-ui. If you want to run a local model through Ollama and still use MCP tools, Dive is built for that combination and Claude Desktop is not.
The second comparison is building your own host against an MCP client library. That gives you exactly the tool gating, logging and deployment shape you want, at the cost of writing and maintaining the UI, the server lifecycle management, the update mechanism and the multi-provider API handling that Dive already ships. Dive's advantage is that all of that exists; its disadvantage is that you inherit its choices, including the unstable authentication flow and the absence of a headless mode.
The third comparison is a managed MCP gateway such as OAPHub itself. Dive is a client for that service as well as a host for local servers, so the two are not mutually exclusive. The distinction is where the server process runs and who patches it. Local servers mean you own the Python and Node dependencies; OAPHub means you do not, and you accept an external dependency for the tools your agent can reach.
Release cadence, licence, and what upgrading costs you
The release history shows v0.14.1 in February 2026, v0.14.2 in March 2026, and v0.14.3 in July 2026. That is a steady but not rapid cadence, with the longest gap between the March and July releases. The project is not archived and its last push is dated after the most recent release, so development is ongoing.
Upgrade cost is partly handled for you. The README lists an auto-update mechanism that checks for and installs the latest version. That reduces the manual work but also means the application can change under you between sessions, which matters if you have pinned behaviour through model_settings.json or depend on a specific MCP server configuration. The README's migration note asserts that local MCP and LLM configurations remain supported and that OAP integration is additive, but that statement covers the OAP change specifically, not future releases.
On licensing, Dive is MIT. That is permissive: it allows modification, redistribution and commercial use, with the usual requirement to preserve the copyright notice and licence text. It is not a copyleft licence, so it imposes no obligation to publish your own changes. None of this is legal advice, and if you plan to redistribute a modified build you should read the LICENSE file in the repository rather than this summary.
The AUR package for Arch is worth flagging separately, because a third-party maintainer controls when it picks up new versions. If you install through paru -S dive-ai, your update timing is that maintainer's, not the project's.
Editorial conclusion
Adopt Dive if you want a desktop MCP host that keeps local server configuration under your control and you are willing to install Python and Node.js yourself on macOS and Linux. Skip it if you need the Tauri build on macOS, since the README marks that combination as not yet available, or if you want a headless host for CI. Before committing, verify the MCP server authentication flow on your own servers, because the README flags it as unstable and subject to frequent re-authorization, and confirm whether the built-in Bash and File Manager tools are acceptable in your environment.
Community notes