In this article
Tools expose model actions, Pipes appear as models, Filters transform messages, and Actions provide user-triggered message operations.
Choose an Open WebUI extension by the operation it adds. A Tool exposes a callable action; a Pipe appears as a model; a Filter transforms messages; an Action adds a user-triggered message operation. These are different extension mechanisms, not competing model settings.
The concrete application boundary
The extensibility documentation separates in-process Python Tools and Functions from external HTTP integrations. In-process code runs with Open WebUI and shares its process resources. External OpenAPI or MCP services remain separate execution owners. Workspace Models, Prompts, Knowledge, and Skills are configuration building blocks rather than arbitrary platform code extensions. This distinction matters when a user merely wants reusable instructions: a model wrapper may suffice, with no plugin necessary. Conversely, placing an API description in a system prompt does not create a functioning Tool. Begin by naming the missing operation, then choose the smallest documented mechanism that actually owns that operation (Open WebUI Extensibility) (Open WebUI Workspace).
A practical route
For a model-invoked lookup, inspect a Tool and its actual input/output behavior. For a custom generation path visible in the model selector, evaluate a Pipe Function. For a button that acts on an existing message, use an Action Function. For systematic input or output transformation, evaluate a Filter. If the needed service already exposes a supported HTTP interface, configure that integration rather than copying its implementation into the application. Review imported code before using it; a popular community entry is not a quality or security review.
A worked example
A user wants two different capabilities: a release-note assistant and a button that converts one completed answer to a project format. The assistant can be a Workspace wrapper with instructions. The button is an Action, because the user triggers it on a message. If the assistant later needs a live lookup, that separate capability may require a Tool. One wrapper name does not implement all three operations.
| Check | Record |
|---|---|
| Reusable instructions | Workspace model configuration over an existing base model. |
| Message button | A user-triggered Action Function operating on the selected message. |
| Model-invoked lookup | A Tool or supported external service connection with observable results. |
Reading the failure correctly
A Pipe selected as a model will not behave like an independently attached Tool. A Filter can alter requests even when the user did not press a message button. Native MCP transport support also has documented limits; do not treat every MCP server transport as interchangeable. Identify the extension type before debugging model instructions (Open WebUI Models).
What completes the check
The decision is complete when the desired operation maps to an execution owner and invocation method. Keep configuration-only changes separate from installed code, so a reusable prompt does not accidentally become a much broader extension task.
Related background: vLLM served-model-name: Fix a Missing API Model, llama.cpp server: a local API from a GGUF model.