When a tool returned an image, for example Open Terminal reading a PNG, a native tool or an MCP screenshot tool, the image was sent to the model even when the model has Vision turned off. A provider serving a text-only model rejects that request, so the reply failed with an error like "At most 0 image(s) may be provided in one prompt", and every later message in the chat failed the same way. With Vision off the model now gets a short "[image]" note in place of each tool image, including images already saved in the chat, so stuck chats work again. The images stay saved, so they reach the model again once Vision is turned on.
Fixes#32720
Choosing Add Details, More Concise, or typing a suggestion under a reply sent the model your original question followed straight by the bare instruction, with the reply itself missing, so it answered the instruction on its own (for example "OK, I'll keep answers shorter") instead of rewriting that reply. The model now receives the reply it is being asked to change, so it returns a shorter, more detailed or altered version of it. Plain Try Again and temporary chats were not affected.
Fixes#33083
* fix: MCP tools that list their arguments under anyOf are called with no arguments
When an MCP tool described its input as alternatives, for example a page by id or by path and locale, and had no top-level list of fields, every argument the model sent was dropped and the tool was called with nothing, so the server rejected the call. Arguments for MCP tools now reach the server as the model sent them, and the MCP server checks them against its own schema. Other tool types still keep only the arguments their schema lists.
Fixes#32898
* refac: shorten the MCP arguments comment
The comment now only says why MCP tools skip the argument filter.
Adding a custom parameter named tools to a model, for example to turn on a provider's native web search, made Open WebUI drop all of its own tools for that model: notes, knowledge, tasks and any tools attached to the model stopped working, and attached files lost their context. Those tools now stay, and the model's custom tools are sent alongside them. API calls that pass their own tools, or an empty list to turn tools off, behave as before.
Fixes#32528
With tool approval set to ask, a knowledge or file tool the user approved ran and answered, but no sources were saved on the reply or shown below it. The same call without approval listed them as usual. The sources of an approved call are now saved and shown the same way.
Fixes#32436
Pipes and tools received None instead of a list of files on messages without attachments, which does not match the docs and breaks plugins that loop over the files. Pipes and tools now get an empty list in that case.
Fixes#32379
When an MCP tool server fails to connect during a chat, the chat shows "Failed to connect to MCP server" but the reason was only logged at debug level, so it never appeared in the logs of a default install. The failure is now logged as an error with the full cause, such as a refused connection or a 401 from the server. The message in the chat is unchanged.
Fixes#32213
Notification targets subscribed to Chat failed stayed silent when the provider answered a chat with an error status, such as a 500, or could not be reached at all. Those failures show up as an error in the chat, but only a few uncommon failures were announced to the targets. Now these failures notify Chat failed targets too, with the error text and a link to the chat.
Fixes#32003
When a chat is named after its first message (title generation off, or the automatic title is blank), a message that starts with a skill picked by typing $ in the message box gave the chat a title like `<$tides-1234|Tides> when is high tide`. The title now shows each picked skill by its name, so the sidebar reads "Tides when is high tide".
Fixes#32019
