ToolKnit Desktop: a local-first Windows workbench for PDF, image, audio and AI file work

The problem ToolKnit Desktop is aimed at

Most file chores arrive one at a time and each one wants its own tool. A PDF needs page numbers, a screenshot needs a transparent background, a spreadsheet needs to become a PDF, a Markdown draft needs a preview, a token needs decoding. The usual answer is a browser tab per job, which means the file is uploaded to somebody's server and the work cannot be scripted later. ToolKnit Desktop takes the opposite position: one Windows application, 65 tools across 12 categories, and the README states the privacy policy as local-first, with files staying on the machine. The audience is narrow and specific. It is a Windows 10 or 11 user who handles documents, images, audio and video often enough to care about batching, and who wants the same operation available from a graphical tool page, from a CLI, and from an IDE agent through MCP. The README describes three working modes and 46 MCP capabilities, so the intent is not a single-purpose utility but a workbench that a script or an agent can drive. If you only need to convert one PDF once, this is a large thing to install for that.

How the desktop, CLI and MCP layers share one file

The architecture the README describes is a Tauri 2.x shell around a local file pipeline. The desktop app is the front end; the CLI ships as the npm package `@toolknit/cli`; the MCP layer exposes 46 capabilities for agent workflows. The README states that the same local file can be previewed in the desktop app, batch processed by the CLI, and called by an MCP agent, with explicit input, output, progress, error and security boundaries. That contract is the interesting part. A batch job is not a black box that either finishes or does not; the README says progress and errors are part of the definition, which matters when a run touches dozens of files. Resource handling follows the same pattern. Heavy editors and algorithm modules load on demand, and the README states that leaving a page releases Workers, canvases, listeners and temporary resources. Two dependencies are pulled in only when needed: a LibreOffice runtime that ToolKnit manages itself, used to render Excel to PDF, and a local model for background removal. Version numbers are kept in step across the desktop app, Tauri, the Rust crates and `@toolknit/cli`, all at 2.3.1, and the release gate covers help mappings for all 65 tools, the 46 MCP capabilities, front-end regression, Rust tests and release safety checks. That is a coherent story. It is also a story told by the maintainer, and the README does not publish a rollback procedure for a batch that writes over files, so treat the output directory as your safety net.

Installing ToolKnit Desktop and running a first batch job

There is no source build in the README's quick path. The README points at the GitHub Releases page for the Windows desktop build, and states that the 2.3.1 installer, the SHA-256 checksum file and the release notes are published there. Download the installer and its checksum, then verify the download before running anything. The README does not print a verification command, so use whatever hashing tool your Windows machine already has and compare the digest against the SHA-256 file from the same release. The README says the installer carries a WebView2 bootstrapper, so a machine without the runtime should be handled during setup. If the app needs elevated rights, the README notes that the admin restart path was made more reliable in 2.3.

The second layer is the CLI, which the README names as `@toolknit/cli`. It is distributed as an npm package, so install it with npm if you want a batch you can script outside the window.

npm install -g @toolknit/cli

After that, the CLI should be on your PATH and able to operate on the same files the desktop app opens. The README does not print a full command reference, so check the CLI's own help output before wiring it into a scheduled job. The third layer is MCP: the README lists 46 MCP capabilities for IDE agent workflows, and the desktop tools, CLI and MCP layer are described as sharing the same input and output boundaries. If you use an agent-capable editor, that is where the 46 capabilities come in. Two first-run behaviours are worth expecting. The app checks GitHub Releases for updates while idle after launch, and the README says the reminder can be postponed and no usage data is uploaded. The Excel to PDF tool will need the managed LibreOffice runtime, and background removal will need its local model, both downloaded on demand.

Where ToolKnit Desktop runs out of road

The first constraint is the platform. The README lists Windows 10 and 11 as the first-release platform and the download badge points at Windows only. There is a web version at toolknit.com that the README presents as the no-install entry point, but the desktop package itself is a Windows product. A team on macOS or Linux cannot adopt the desktop app as it stands.

The second constraint is the dependency model. Excel to PDF is not a pure JavaScript conversion; the README says it renders through a local LibreOffice runtime that ToolKnit manages, and background removal uses a model downloaded on demand. Both are reasonable choices for a local-first tool, and both mean the first use of those tools needs a working network and enough disk space. On an air-gapped machine, or behind a proxy that blocks the download, those two tools are unavailable even though the rest of the app works.

The third is scope. Sixty-five tools in one window is a lot of surface, and the README's own 2.3 notes include fixes for PDF.js on older WebView2 builds and for tool-page navigation, export dialogs and rounded rendering. Breadth at this scale means the least-used tool is the least-tested one. If your job is a single well-defined conversion at high volume, a dedicated converter you can inspect and script is a better fit than a workbench. And if you need the operation to run on a server in CI rather than on a person's desktop, this is the wrong shape of product.

How it differs from a browser-based file converter

The obvious alternative is a web converter such as the one at toolknit.com itself, or any of the many browser tools that accept an upload and return a processed file. The difference is not the feature list; it is where the bytes go. A browser converter requires the file to leave the machine and reach a server, and it usually cannot be called from a script. ToolKnit Desktop's stated policy is local-first, and the README also offers the web version as a separate entry point for people who want no installation, which makes the trade-off explicit rather than hidden.

A second alternative is a command-line toolchain assembled from single-purpose utilities, driven by a shell script. That approach wins on transparency and on server deployment, and it loses on preview and on interactive editing. ToolKnit's answer is to expose both: the desktop app for the visual work, the CLI for the batch, and MCP for the agent. The cost of that answer is a larger install and a dependency on the app's own runtime management for LibreOffice and the background-removal model. Pick the workbench when the same file needs to be looked at and then processed at volume; pick the script when it only needs to be processed.

Licence, maintenance and what an upgrade costs

ToolKnit Desktop is licensed under Apache-2.0, and the repository carries both a LICENSE and a NOTICE file. Apache-2.0 permits commercial use and modification and requires that the licence and notices be preserved; the NOTICE file exists precisely so that attribution travels with redistributions. If you fork the app and ship it inside a company, keep LICENSE and NOTICE intact. That is a description of the licence text, not legal advice, and the bundled LibreOffice runtime and the background-removal model may carry their own terms, which the README does not spell out.

On maintenance, the evidence is recent and concrete: the last push to the default branch was on 2026-09-13, and releases v2.3.0 and v2.3.1 both landed on 2026-08-31, with v2.1.1 on 2026-08-25. The repository is not archived. The README also describes a release gate that runs front-end regression, Rust tests and release safety checks before a version goes out.

Upgrade cost is where the version discipline helps. The desktop app, Tauri, the Rust crates and `@toolknit/cli` are pinned to the same version, 2.3.1, so a CLI on a different number than the app is a mismatch you can detect by reading the version string. The README does not document a rollback path, and it does not describe a migration step for local drafts or settings between 2.3.0 and 2.3.1. Before upgrading a machine that holds work in progress, export the Markdown drafts the document editor keeps locally.

Editorial conclusion

Adopt ToolKnit Desktop if your file work happens on Windows, the files should not leave the machine, and you want the same operation reachable from a GUI, the CLI and an MCP agent. Do not adopt it if you need macOS or Linux clients, or if you cannot let the app download a LibreOffice runtime and a background-removal model on first use. Before rolling it out, verify three things on a real machine: that the WebView2 runtime is present or the installer can bootstrap it, that the on-demand dependency download completes on your network, and that the SHA-256 file published with the release matches the installer you downloaded.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. ZihangDong/toolknit-desktop on GitHub