FluxDown: a Rust download manager with an MCP server for AI agents

What FluxDown replaces, and for whom

FluxDown is a download manager. The README positions it directly against Internet Download Manager, with a comparison table that lists price, open source status, platforms, BitTorrent, eD2K, HLS and DASH support, dynamic segmentation, browser extension and advertising. The claim it makes for itself is breadth: one program that handles HTTP/HTTPS, FTP, BitTorrent, eD2K, HLS and DASH, rather than a browser downloader plus a separate torrent client plus a streaming downloader.

The audience is implied by the packaging table rather than stated. Desktop builds cover Windows x64 and ARM64, macOS Intel and Apple Silicon, and Linux x64. Android builds are split per ABI. There is also a headless server line for NAS and server hardware, distributed as a Docker image, Synology DSM 6/7 .spk, QNAP .qpkg, OpenWrt .ipk, plus Unraid, CasaOS and ZimaOS templates. Someone running a home NAS who wants downloads to continue without a desktop session is clearly in scope.

The second audience is less obvious and more interesting: people who want an AI client to manage their downloads. The README calls this "AI-agent ready" and describes a built-in MCP server with twelve tools. That is the part of this project that is not simply a reimplementation of an existing category.

How the Rust engine, Flutter UI and browser extension fit together

The architecture section of the README is explicit about the split. Flutter renders the UI. A Rust engine does the work. The README describes the boundary as "zero-FFI", with the two sides communicating through Rinf signals. The browser extension is a separate process that reaches the engine through Native Messaging.

The README's diagram names the pieces: the extension is built with WXT, it talks over Native Messaging to a binary called fluxdown_nmh, which connects over a named pipe on Windows or a Unix socket elsewhere to a component labelled hub, described as an FFI adapter. The Flutter UI connects to that same hub through Rinf signals. Below the hub sits fluxdown_engine, which fans out to the protocol implementations: HTTP/HTTPS, FTP and BitTorrent are the ones visible before the diagram is truncated.

The repository layout matches this. Cargo.toml declares a workspace whose members are native/* and crates/*, so the Rust side is split into several crates rather than one binary. The MCP layer is named in the README as native/api/src/mcp.rs, sitting on the same ApiHost trait that backs the REST management API and an aria2-compatible JSON-RPC surface. That detail matters: MCP is not a separate daemon, it is another front end on the same host abstraction. The README states plainly that no extra process is needed.

One build detail worth noting from Cargo.toml: the release profile sets strip = true, opt-level = "z", lto = "fat" and codegen-units = 1, all aimed at binary size. The same file carries a comment warning that panic = "abort" is deliberately not set, because the engine's download_manager relies on catch_unwind to recover from task panics. That is a real constraint on anyone who wants to shrink the binary further.

Installing FluxDown and adding your first download over MCP

The README does not give a command-line install for the desktop application. It points at GitHub Releases and the project website's download section, and lists the package formats per platform: setup.exe and portable .zip on Windows, .dmg and portable .tar.gz on macOS, .AppImage, .deb, Arch .pkg.tar.zst and portable .tar.gz on Linux, per-ABI or universal .apk on Android. For NAS and server use it points at a Docker image published to ghcr.io under zerx-lab/fluxdown-server.

So the practical first step is to fetch the artifact for your platform from the releases page and run the installer or the portable binary. There is no documented package-manager command for the desktop builds in the README, so do not expect one.

The MCP server is where a first real use is documented. It listens on the local API port and speaks Streamable HTTP, described as JSON-RPC 2.0 over a single POST to /mcp. The endpoint given in the README is http://127.0.0.1:17800/mcp, local-only by default. To turn it on in the desktop application, go to Settings, then API Service, and toggle the MCP endpoint. The README states a token is generated automatically. The headless server enables the endpoint by default.

Authentication is a bearer token, passed either as an Authorization header or as an X-FluxDown-Token header. The README shows the client configuration for an MCP-capable client as JSON:

{
  "mcpServers": {
    "fluxdown": {
      "url": "http://127.0.0.1:17800/mcp",
      "headers": { "Authorization": "Bearer <your-token>" }
    }
  }
}

After pasting that into your client's MCP configuration and replacing the placeholder with the generated token, the client should list twelve FluxDown tools. The one you would call first is download_add, which the README says creates a task for HTTP/HTTPS, FTP, magnet or BitTorrent. download_list then lists tasks with progress, speed and status, and accepts an optional status filter. Pause, resume, remove, queue_list and the three RSS tools round out the set.

Where FluxDown's MCP surface stops short of its protocol list

The gap between the feature table and the MCP tool table is the most concrete limitation in the README. The feature table claims dedicated engines for HTTP/HTTPS, FTP, BitTorrent, eD2K and HLS and DASH. The MCP tool table lists download_add as accepting HTTP/HTTPS, FTP, magnet and BitTorrent. eD2K, HLS and DASH do not appear in the tool description.

That does not mean those protocols are unsupported in the application. It means an AI agent driving FluxDown through MCP cannot be assumed to be able to start an eD2K, HLS or DASH download, at least not from the documented tool signature. If your workflow depends on the agent handling streaming captures, verify this against the actual tool schema before building on it.

The second limitation is release maturity. The three most recent releases are all tagged v0.4.8-rc.5, across the main application, the server line and the mobile line. These are release candidates, not stable tags. The README does not document a rollback path or a downgrade procedure, and it does not describe how download state behaves if you move between versions. Since full download state is persisted in SQLite with WAL, a version change that touches the schema is the kind of thing you would want documented before putting the tool in front of a long queue.

The third is platform asymmetry that the comparison table flattens. The table lists "Windows / macOS / Linux / NAS / Android" as a single row against IDM's "Windows only". The packaging table shows those are not equal experiences: Linux is listed for x64 only, Android ships per-ABI APKs, and the NAS line is a separate headless server build rather than the desktop application. If you are on Linux ARM64 desktop, the desktop row does not cover you.

FluxDown against aria2 and against IDM

The README itself names the two comparisons worth making. It describes an aria2-compatible JSON-RPC surface, and it builds a feature table against IDM.

Against IDM, the difference is licensing and platform reach rather than mechanism. IDM is closed source, Windows only, and priced at the figure the README quotes. FluxDown is AGPL-3.0, runs on five platform families, and adds BitTorrent and eD2K, which IDM does not have according to the table. Both are listed as supporting dynamic segmentation, so the segmentation approach is not where they diverge. Where they diverge is that FluxDown gives you the source and a headless server build, and IDM gives you a Windows desktop application with a long track record that this README does not attempt to measure.

Against aria2, the difference is the shape of the program. aria2 is a command-line daemon with an RPC interface; you bring your own front end. FluxDown ships its own Flutter UI, a browser extension, a system tray, named queues and a segment visualization. It also exposes an aria2-compatible JSON-RPC endpoint, which means existing aria2 clients may be able to talk to it. If your reason for using aria2 is that it is a small daemon you script against, FluxDown is a much larger surface for the same core job. If your reason is that you want a GUI and a browser takeover, aria2 leaves that to you and FluxDown does not.

Licence and the cost of keeping up

FluxDown is AGPL-3.0. That is a strong copyleft licence with a network clause. If you run a modified FluxDown as a service that other people interact with over a network, the licence's terms are the ones to read, and the README does not summarise them for you. The practical implication for most readers is narrower: bundling FluxDown into a proprietary product, or shipping a modified build without source, is the situation where the licence choice starts to matter. This is not legal advice; read the LICENSE file in the repository.

On upgrade cost, the README supports a few observations and no more. The last push to the repository was on 2026-08-24, and the three most recent releases carry the same date. The release candidate numbering means the project is publishing pre-release tags across all three product lines at once, so a version bump touches the desktop app, the server and the mobile build together. The README does not document a migration procedure between versions, and it does not describe how the SQLite download state is upgraded. The Cargo.toml pins several dependencies to specific git revisions, including a patched librqbit and a specific revision of gpui-component, which means building from source tracks upstream commits rather than published crates. Anyone building rather than downloading a release should expect that pinning to matter.

Editorial conclusion

FluxDown fits people who want a local-first download manager that also exposes its queue to an AI client, and NAS users who want the headless Docker image. If you need a stable release rather than a release candidate, or you cannot accept AGPL-3.0 obligations in a bundled product, this is not the build to adopt. Before installing, check the releases page for a non-rc tag and confirm which protocol engines you actually need, because the README's protocol list is longer than the MCP tool list.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes