[GH-ISSUE #16409] feat: Simplify tools and functionality ecosystem #33423

New Issue

GiteaMirror · 2026-04-25T07:19:57-05:00

GiteaMirror commented

2026-04-25 07:19:57 -05:00

Originally created by @Hegghammer on GitHub (Aug 9, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/16409

Check Existing Issues

I have searched the existing issues and discussions.

Problem Description

Open WebUI is a fantastic tool -- huge thanks to everyone who has helped build it.

But the ecosystem of functionalities and extensions has grown to become quite complicated. I'm not a developer, but I am not completely lost behind a computer either, and it has taken me weeks to wrap my head around the various concepts and functionalities and their location in the settings. The documentation helps, but it is often on the abstract side, and its structure doesn't quite match what one experiences in the UI.

For my own records, I tried to write up a plain language overview of this ecosystem, from the point of view of a non-expert user who just wants to use LLMs and plug in various extra functionalities. It looks something like this:

Capabilities are functionalities that are built in to Open WebUI and that models can call if they so decide.
- Capabilities show up under the prompt window as individual icons (unlike Tools, which are listed if you click the spanner icon and togglable if you click the plus icon).
- The system-wide settings and toggles for these capabilities are built into the OWU's settings tree, but feature in different places. For example, Web search is in Admin Panel > Settings > Web Search, Upload is in Admin Panel > Settings > Documents, and Code execution is in Admin Panel > Settings > Code execution.
- Capabilities can also be toggled on and off for individual models in Workspace > Models > MODEL > Capabilities.
Tools are functionalities that the user imports to OpenWebUI (typically from Open WebUI Community) and that models can call if they so decide.
- Some tools seek to improve on the built-in capabilities and therefore duplicates them. For example, there are several web search tools, and if you use one of them, it is best to turn off the built-in web search capability.
- The settings for tools live in Workspace > Tools. Here you can tune them (through "Valves") and toggle them on or off globally.
- You can also toggle them on or off for individual models in Workspace > Models > MODEL > Tools
- Confusingly, there are other Setting entries called "Tools" -- Admin panel > Settings > Tools and Settings > Tools -- but these are not for tools, but for tool servers, which is something different.
Tool servers are functionalities made available to the models from services that run outside of Open WebUI and are accessible via API; for example, a RAG server or a Filesystem server.
- The settings for these are in Admin panel > Settings > Tools (for systemwide ones) and in Settings > Tools for user-specific ones.
Functions is an umbrella term for three rather different things: Actions, Filters, and Pipes.
- Filters are functionalities that get applied to all messaging with the models (as opposed to Tools, which only get used if the content of the prompt calls for it).
- Actions are functionalities that become available as a button in the chat interface. For example, "Save outputs" give you a little save icon below the response in the Chat interface.
- Pipes are special scripts that make new functionalities show up in the model list, for example the "OpenRouter integration" pipe or the "Deep Research at Home" pipe.
- Function settings live in Admin panel > Functions
- You can toggle filters for individual models in Workspace > Models > MODEL > Filters
- You can toggle actions for individual models inWorkspace > Models > MODEL > Actions
Pipelines are preconfigured sequences of steps that process the input and/or the output in some way. This is a more advanced functionality that I personally haven't used yet.
- Their Admin panel > Settings > Pipelines

Phew. And this is without discussing Knowledge and other features.

There are several sources of confusion here:

There are a lot of different names to keep track of
Tools and capabilities do roughly the same thing, except one is built-in and the other is imported
The entries for tool settings and tool server settings are both called "tools"
The term "functions" is overaggregated, insofar as it refers to three different functionalities that operate quite differently from one another
The structure of the documentation does not match the structure of the UI. To mention just one example: in the docs, the header Pipelines includes the sub-headers "Filters", "Pipes", and "Valves". But "Pipelines" is a separate thing with its own entry in UI's Admin Panel, whereas "Filters" and "Pipes" feature as subsets of "Functions" (alongside "Actions") in Admin Panel > functions. Meanwhile, "Valves" are conceptually a further level down insofar as they are effectively settings for individual functions. As well as for tools.

I could go on. The whole thing is rather confusing and would benefit from a general overhaul. The complexity probably deters quite a few amateur users. I am not saying that the UI should be minimalist -- customizability is half the attraction -- but it could be more logical and intuitive than it is today.

Desired Solution you'd like

I don't have a clear idea of how to fix it, because I don't know enough about about the history of the project. I realise that there are probably good reasons why things are the way they are today, but I would urge the developers to look for ways to simplify things going forward.

As I see it, there are three main problems to solve:

The conceptual nomenclature
The organization of the UI
The organization of the documentation

On item 1, I think it would help to have labels/names that reflect what the various features do for the user rather than how they work on the back end. For example, "capabilities", "tools" and "tool servers" could be aggregated to "tools" (just subcategorize them as internal, imported, and server-based) since they correspond, in terms of functionality, to what most people understand by that concept in an LLM context. Conversely, "functions" should be disaggregated, since filters, actions and pipes do very different things for the user. Solutions to items 2 and 3 will flow from decisions made on item 1.

Alternatives Considered

No response

Additional Context

No response

Originally created by @Hegghammer on GitHub (Aug 9, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/16409 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description Open WebUI is a fantastic tool -- huge thanks to everyone who has helped build it. But the ecosystem of functionalities and extensions has grown to become quite complicated. I'm not a developer, but I am not completely lost behind a computer either, and it has taken me weeks to wrap my head around the various concepts and functionalities and their location in the settings. The documentation helps, but it is often on the abstract side, and its structure doesn't quite match what one experiences in the UI. For my own records, I tried to write up a plain language overview of this ecosystem, from the point of view of a non-expert user who just wants to use LLMs and plug in various extra functionalities. It looks something like this: - **Capabilities** are functionalities that are built in to Open WebUI and that models can call if they so decide. - Capabilities show up under the prompt window as individual icons (unlike Tools, which are listed if you click the spanner icon and togglable if you click the plus icon). - The system-wide settings and toggles for these capabilities are built into the OWU's settings tree, but feature in different places. For example, Web search is in `Admin Panel > Settings > Web Search`, Upload is in `Admin Panel > Settings > Documents`, and Code execution is in `Admin Panel > Settings > Code execution`. - Capabilities can also be toggled on and off for individual models in `Workspace > Models > MODEL > Capabilities`. - **Tools** are functionalities that the user imports to OpenWebUI (typically from [Open WebUI Community](https://openwebui.com/#open-webui-community)) and that models can call if they so decide. - Some tools seek to improve on the built-in capabilities and therefore duplicates them. For example, there are several web search tools, and if you use one of them, it is best to turn off the built-in web search capability. - The settings for tools live in `Workspace > Tools`. Here you can tune them (through "Valves") and toggle them on or off globally. - You can also toggle them on or off for individual models in `Workspace > Models > MODEL > Tools` - Confusingly, there are other Setting entries called "Tools" -- `Admin panel > Settings > Tools` and `Settings > Tools` -- but these are not for tools, but for tool *servers*, which is something different. - **Tool servers** are functionalities made available to the models from services that run outside of Open WebUI and are accessible via API; for example, a RAG server or a Filesystem server. - The settings for these are in `Admin panel > Settings > Tools` (for systemwide ones) and in `Settings > Tools` for user-specific ones. - **Functions** is an umbrella term for three rather different things: Actions, Filters, and Pipes. - **Filters** are functionalities that get applied to all messaging with the models (as opposed to Tools, which only get used if the content of the prompt calls for it). - **Actions** are functionalities that become available as a button in the chat interface. For example, "Save outputs" give you a little save icon below the response in the Chat interface. - **Pipes** are special scripts that make new functionalities show up in the *model list*, for example the "OpenRouter integration" pipe or the "Deep Research at Home" pipe. - Function settings live in `Admin panel > Functions` - You can toggle filters for individual models in `Workspace > Models > MODEL > Filters` - You can toggle actions for individual models in`Workspace > Models > MODEL > Actions` - **Pipelines** are preconfigured sequences of steps that process the input and/or the output in some way. This is a more advanced functionality that I personally haven't used yet. - Their `Admin panel > Settings > Pipelines` Phew. And this is without discussing Knowledge and other features. There are several sources of confusion here: - There are a lot of different names to keep track of - Tools and capabilities do roughly the same thing, except one is built-in and the other is imported - The entries for tool settings and tool server settings are both called "tools" - The term "functions" is overaggregated, insofar as it refers to three different functionalities that operate quite differently from one another - The structure of the documentation does not match the structure of the UI. To mention just one example: in the docs, the header [Pipelines](https://docs.openwebui.com/pipelines/) includes the sub-headers "Filters", "Pipes", and "Valves". But "Pipelines" is a separate thing with its own entry in UI's Admin Panel, whereas "Filters" and "Pipes" feature as subsets of "Functions" (alongside "Actions") in `Admin Panel > functions`. Meanwhile, "Valves" are conceptually a further level down insofar as they are effectively settings for individual functions. As well as for tools. I could go on. The whole thing is rather confusing and would benefit from a general overhaul. The complexity probably deters quite a few amateur users. I am not saying that the UI should be minimalist -- customizability is half the attraction -- but it could be more logical and intuitive than it is today. ### Desired Solution you'd like I don't have a clear idea of how to fix it, because I don't know enough about about the history of the project. I realise that there are probably good reasons why things are the way they are today, but I would urge the developers to look for ways to simplify things going forward. As I see it, there are three main problems to solve: 1. The conceptual nomenclature 2. The organization of the UI 3. The organization of the documentation On item 1, I think it would help to have labels/names that reflect *what the various features do for the user* rather than how they work on the back end. For example, "capabilities", "tools" and "tool servers" could be aggregated to "tools" (just subcategorize them as internal, imported, and server-based) since they correspond, in terms of functionality, to what most people understand by that concept in an LLM context. Conversely, "functions" should be disaggregated, since filters, actions and pipes do very different things for the user. Solutions to items 2 and 3 will flow from decisions made on item 1. ### Alternatives Considered _No response_ ### Additional Context _No response_

GiteaMirror closed this issue

2026-04-25 07:19:58 -05:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#33423