open-webui-tools ships two inventories of itself that do not match

Two inventories of the same collection with different membership

The What's Inside section is divided into three headings and counts cleanly. Sixteen tools, nine function pipes and six filters, which is 31 entries. The prose above it says 20+ specialized tools and functions, and the repository description says over 15 specialized tools, so three numbers describe one collection.

Then the table of contents, also numbered, also reaching 31, and listing a different set. It includes a Cloudflare Workers AI Image Generator and a SearxNG Image Search Tool, neither of which appears in the tools list. It includes an OpenRouter Image Pipe, which is not in the function pipes list. And it files Flux Kontext under pipes while the list above files it under tools.

Both totals land on 31 by coincidence, which is what makes it easy to miss. The composition differs in at least four places, so a reader choosing what to install from either list will get a different set.

The last entry does not resolve either. It is numbered 31, begins with Semant, and stops there, which is where the document's own outline ends.

Manual installation is copy and paste, so there is no update path

Two routes are offered and the first is recommended. The Open WebUI Hub route points at a user page on openwebui.com, where you browse the collection, click Get for the tools you want, and follow the installation prompts inside your instance.

The manual route is:

1. Copy the `.py` files from `tools/`, `functions/`, or `filters/` 2. Navigate to Open WebUI Workspace > Tools/Functions/Filters 3. Paste the code, provide a name and description, then save

Step three is the whole story. A tool is one Python file pasted into a text box, and the name and description are typed by whoever installs it rather than read from a manifest. There is no package metadata in the repository, no requirements file, and nothing that tells Open WebUI which file is which tool. That is a workable model for trying one function, and a poor one for keeping 31 of them current, since a new version of a file arrives as a new paste.

Note also that the instruction names three directories. The repository has two more at the root, Pipelines/ and Extras/, and neither appears in the install steps.

Three tools make a point of needing no API key

Several entries advertise what they do not require, which is the most useful information in the list.

arXiv Search is described as academic paper discovery with no API key required. SerpBase Google Search adds that no self-hosted instance is needed, and returns organic results, featured snippets and AI Overviews. OutageDeck Provider Status checks provider health and incident timelines without an API key.

The rest of the collection is a different proposition. Pexels Media Search needs the Pexels API, Hugging Face Image Generator needs a Hugging Face key, Perplexica Search talks to a Perplexica API, and Atlas Cloud Media Generator and Google Veo are third party services. The prerequisites section names ComfyUI for the image and music tools and Mopidy for the music controller, and lists API keys with Hugging Face and Tavily as examples.

The floor for all of it is Open WebUI 0.6.0 or newer, recommended rather than required, and Python 3.8 or higher.

Seven entries depend on a ComfyUI box or a paid service

Grouping the collection by what it actually needs to run is more useful than the three headings give you.

Five entries are ComfyUI workflows: image to image editing with Qwen Edit 2509 and multi-image support, ACE Step 1.5 audio, the legacy ACE Step audio tool, text to video on a default WAN 2.2 workflow, and Flux Kontext for image editing. Each of them needs a ComfyUI instance reachable from Open WebUI, with the models and custom nodes that workflow expects, and the collection does not document which.

Then there are hosted services: Atlas Cloud for image, editing and image or audio to video, Google Veo for text to video and image to video with only one image supported as input, MiniMax through an OpenAI-compatible API with M3 at a 1M context and image and video input alongside M2.7, and OpenRouter for the citation filter. Mopidy drives a music server, and the Letta Agent pipe attaches to another agent runtime.

So the honest count is three tools that work with a key or no key and nothing else, five that need your own GPU box, and a long tail of pipes that reach out to services with their own billing.

The repository root holds files that are not Open WebUI tools

The root directory reads as a personal workspace rather than a curated collection. Alongside `.gitignore`, `LICENSE`, `README.md`, `SECURITY.md` and the three tool directories, there is:

- `d10_solver.py`, a single script at the root - `dice-3d/`, a directory whose name says what it holds - `DEPRECATED_README.txt` - `test_bs4.py`, a test file at the root next to a `tests/` directory - `Extras/` and `Pipelines/`, capitalised, beside the lowercase `tools/`, `functions/` and `filters/` - `img/` for images

None of these are mentioned in the install instructions or the tool list. The mixed casing matters a little on case sensitive filesystems, and the two extra directories mean the repository is wider than the three folders the documentation tells you to copy from.

The stray solver and the dice directory are the kind of artefact that usually explains itself once you know who wrote the repository, and they are not a functional problem. They do make it harder to tell what a given file in the collection is meant to be.

The feature list is marketing, the tool names are the documentation

There is a Key Features section, and it is seven adjectives. Plug-and-Play, Visual Integration, AI-Powered, Academic Focus, Creative Tools, Smart Routing, Document Processing. Every one of those words is true of at least one entry and none of them tells you which.

The Configuration section is more honest and equally thin. It says most tools are designed to work with minimal configuration, then names four areas: API keys for the tools that need them, ComfyUI integration for the image and music generators, model selection, and enabling filters in your model configuration. There is no per-tool key list, no table of which pipe needs which variable, and no statement of what the filters do to a conversation beyond their one line summaries.

The individual entries are the actual documentation, and they are precise: which direction an image tool works, that one video model accepts a single image, that a MCTS pipe is a search strategy, that a filter is toggleable. The Doodle Paint filter is described as opening a paint canvas before each message is sent, which is a behaviour you can reason about before installing it.

Thirty one files, no releases, and one update channel

There are no GitHub releases, and the last push is dated 2026-08-29. The project is MIT licensed and written in Python, and it is a collection rather than a package: no setup script, no dependency manifest, no test runner configuration for the tools themselves, and no version marker anywhere in the README that would tell an installer which revision they pasted.

That leaves the Hub as the only channel that can carry an update. A file installed by paste stays at whatever revision you pasted, and nothing in the repository connects a tool file to a release. For a collection whose individual entries depend on other people's models and services, that means the breakage surface is the upstream API drifting rather than the collection changing.

The SECURITY.md at the root is worth pairing with that. A collection that runs inside a chat interface, with pipes that reach third party services and a filter that rewrites every outgoing message, is the kind of thing to read once before installing it into an instance you trust, and the repository does not say how the individual files are reviewed.

Editorial conclusion

open-webui-tools is a good browsing catalogue for people who already run Open WebUI and know which three or four things they are missing, because the entries are specific enough to choose from. It is a weaker choice as a set to install wholesale. Three things to settle first. Which inventory you are trusting, since the tool list and the table of contents disagree about membership and about whether four items are tools or pipes. Where your files come from, because the manual route is a paste with no update path and the Hub is the only channel that carries one. And what each entry needs before it works, since five want a ComfyUI instance, several want hosted keys, and the configuration section names no variables. The unrelated files at the root are noise rather than risk, but the missing version marker is worth raising if you plan to depend on any single pipe.

Frequently asked questions

Official sources

1. Haervwe/open-webui-tools on GitHub
2. Issues
3. License: MIT
4. README