The model does nothing with the result of a native tool call

[Banbury]

Bug Report

Installation Method

Docker

Environment

• Open WebUI Version: 0.5.9

• Ollama (if applicable): 0.5.7

• Operating System: Windows 11

• Browser (if applicable): Firefox 134.0.2

Confirmation:

• [ x] I have read and followed all the instructions provided in the README.md.
• [ x] I am on the latest version of both Open WebUI and Ollama.
• [ x] I have included the browser console logs.
• [ x] I have included the Docker container logs.
• [ x] I have provided the exact steps to reproduce the bug in the "Steps to Reproduce" section below.

Expected Behavior:

The result of a native tool call is handed to the model for further processing.

Actual Behavior:

The model does nothing with the result of a native tool call.

Description

Bug Summary:
Native tool calling works in principle, but the the model is not called again with the result. So no answer is generated.

Reproduction Details

Steps to Reproduce:

• Activate native tool calling for a model (e.g. LLama 3.1 or 3.2).
• Open a chat and activate a tool.
• Ask the model something, that triggers the function call.
• Open Webui creates an empty message, that only contains the details of the tool call, but no further processing by the model.

<details type="tool_calls" done="true" content="[{&quot;index&quot;: 0, &quot;id&quot;: &quot;call_2cf4317d-058f-4b18-b592-578355b950fc&quot;, &quot;type&quot;: &quot;function&quot;, &quot;function&quot;: {&quot;name&quot;: &quot;dice_roll&quot;, &quot;arguments&quot;: &quot;{&#x27;dice_str&#x27;: &#x27;2d10&#x27;}&quot;}}]" results="[{&quot;tool_call_id&quot;: &quot;call_2cf4317d-058f-4b18-b592-578355b950fc&quot;, &quot;content&quot;: 16}]">
<summary>Tool Executed</summary>

> dice_roll: 16
</details>

Logs and Screenshots

Browser Console Logs:
console-export-2025-2-5_16-42-23.txt

Docker Container Logs:
2025-02-05 16:43:56 open-webui | INFO: 192.168.32.1:42608 - "POST /api/v1/chats/ea42d230-9aa4-4bc7-acbb-8ac2fe7b9490 HTTP/1.1" 200 OK
2025-02-05 16:43:56 open-webui | INFO: 192.168.32.1:42608 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 OK
2025-02-05 16:43:56 open-webui | INFO [open_webui.utils.middleware] tools={'dice_roll': {'toolkit_id': 'dice_roller', 'callable': <function Tools.dice_roll at 0x7f18997a87c0>, 'spec': {'name': 'dice_roll', 'description': '\n Rolls a number of dice and returns the result.\n ', 'parameters': {'properties': {'dice_str': {'description': 'A text describing a how many dice should be rolled. E.g. "d100" is one 100-sided die, "2d6" are two six sided dice. A modifier also can be added, e.g. "3d10+2".', 'type': 'string'}}, 'required': ['dice_str'], 'type': 'object'}}, 'pydantic_model': <class 'open_webui.utils.tools.dice_roll'>, 'file_handler': False, 'citation': False}}
2025-02-05 16:43:57 open-webui | INFO: 192.168.32.1:42608 - "POST /api/chat/completions HTTP/1.1" 200 OK
2025-02-05 16:43:57 open-webui |
2025-02-05 16:43:57 open-webui |
2025-02-05 16:43:57 open-webui | {'index': 0, 'id': 'call_2cf4317d-058f-4b18-b592-578355b950fc', 'type': 'function', 'function': {'name': 'dice_roll', 'arguments': "{'dice_str': '2d10'}"}}
2025-02-05 16:43:57 open-webui |
2025-02-05 16:43:57 open-webui |
2025-02-05 16:43:57 open-webui | INFO: 192.168.32.1:42608 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 OK
2025-02-05 16:43:57 open-webui | INFO: 192.168.32.1:42620 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 OK
2025-02-05 16:43:57 open-webui | INFO: 192.168.32.1:42612 - "POST /api/chat/completed HTTP/1.1" 200 OK
2025-02-05 16:43:57 open-webui | INFO: 192.168.32.1:42608 - "POST /api/v1/chats/ea42d230-9aa4-4bc7-acbb-8ac2fe7b9490 HTTP/1.1" 200 OK
2025-02-05 16:43:57 open-webui | INFO: 192.168.32.1:42608 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 OK

[tjbck]

It is called, llama3 models are known for being unreliable.

[Banbury]

The tool is called reliably. I get a result every time. The log also shows this. But after the tool call model completion needs to be called again with the result AFAIK.
I have been using Llama 3's tool calling in Flowise and Griptape, and it rarely if ever fails with only one tool. The more tools I add, the less reliable it becomes.
I still think this is a bug.

[RodolfoCastanheira]

Does webui do the usual behavior of sending the tool output to the model, after running the tool?

Because I'm having the same problem as OP.

[lowlyocean]

I am having same issue, but with different model (not llama 3). I suspect the tool output isn't being sent to the model as a standalone message as per Get Weather example from OpenAI. @tjbck was this native tool calling feature only tested with remotely hosted models or was it tested also locally e.g. Ollama? If so, is it tested with both Ollama and OpenAI connection types?

[lowlyocean]

Did anyone manage to get this working?

[xblaauw]

I would like to get more clear information about this as-well, it is not very well documented how this is supposed to work - how to check if its working etc.

[rvkwi]

having the same issue with several models trying to figure out how to use multiple tool calls, mistral-small v3 for example. very reliable calling and execution (only a single time tho), no response usually (also not really able to call multiple in this). i feel like i'm doing it wrong in my tools but some documentation would really help.

[lowlyocean]

I don't think multiple tool calls is supported, we are just discussing Native tool calls here.

You may get what you want by checking out the Pipe mentioned in the description of this video https://youtu.be/4qrVoMx4UV8?si=XZTv5LMxRjgPHxY3

[rvkwi]

ah thanks! no i know, it is supported now since the last update (why i was tinkering with native. it was in 0.5.12 > (🛠️ Multiple Tool Calls Support for Native Function Mode: Functions now can call multiple tools within a single response, unlocking better automation and workflow flexibility when using native function calling.)

but tinkering with native made me realize that i ran into the same issue with the models running things fine, it executing, then the model doing nothing with it

[lowlyocean]

Looks like 0.5.12 was just released yesterday. I just updated to it today, and see that it's still got the issue reported by OP and that also it doesn't call multiple tools. This is with MFDoom/deepseek-r1-tool-calling:14b and Ollama connection type. If I use that same model with Native Tool Calling Pipe and just leave Function Calling valve set to Default, it takes care of both issues. However this pipe works, it's more effective than the official code

[Banbury]

Someone needs to reopen this as a bug. Maybe if the owner hears it from multiple sides, he will listen.

[lowlyocean]

Another option, may want to try Libre Chat which seems to support this feature

[Banbury]

I am not your dog, and I would prefer, if you stay civil. Otherwise I will have nothing else to say to you.

[therealmichaelberna]

Hey guys, I had a similar issue and wanted to see if this may be related

#9442

[yzjJosh]

I have the same problem using llama3-groq-tool-use. The model consistently responds empty chat when native tool calling is enabled.

[lowlyocean]

Still not fixed as of 0.5.16. I also tried just "continuing" a temporary chat to see if it'd spit out the answer. It doesn't - it just repeats the tool call and then shows no response

[lowlyocean]

This looks like it's been fixed in 0.5.17 (just wish there was a way to set Native as the default)

[Banbury]

For me it's still the same. The tool is executed, but the model isn't called with the result. So I don't get an answer.

[rvkwi]

My issues seems to have been solved. Using mistral small 2501 still, since the last update it can now use native tool calling no problem and respond normally. Even tho I did not see any fix related to this, something has fixed it.

[ProjectMoon]

It probably heavily depends on the model itself. I've had the best (but still mixed) results with Mistral Small 3 too. But I hesitate to make it the default mode for the model in OpenWebUI...

[clang88]

I'm testing this right now with the MCP/mcpo/OpenAPI tools and unfortunately I am running into the same issue as OP. I tried it with llama 3.2 and OpenAI GPT4o/GPT4o-Mini models. It always just returns the tool response and does not generate any message.
Open WebUI 0.6.5
Native

Default

The call was made both times:

Calling endpoint: add, with args: {'a': 8, 'b': 3}
[04/15/25 15:27:25] INFO     Processing request of type CallToolRequest                                                                        server.py:534
INFO:     172.18.0.2:49478 - "POST /add HTTP/1.1" 200 OK
Calling endpoint: add, with args: {'a': 8, 'b': 3}
[04/15/25 15:28:04] INFO     Processing request of type CallToolRequest                                                                        server.py:534
INFO:     172.18.0.2:58774 - "POST /add HTTP/1.1" 200 OK

[Fjack92]

I am also facing a similar issue.

I am attempting to chain together multiple tool calls, where the output of one tool is used in the reasoning of the next tool. I am implementing this for home assistant where it would need to take the user's query, determine which entity in the home assistant instance is relevant, and then take the action the user requested.

Often times it will succeed in pulling the list of entities, but it will not take the action. It would be cool to see a more robust observability into why a model chose a particular set of actions..., but I think that's outside the scope of this thread.

[hiper2d]

Same thing. The MCP server is being called, but the model acts as if it doesn't get any answer

[PlebeiusGaragicus]

Also had the same issue - cannot remember how I encountered it.... but I noticed a perfect tool call in the logs - but Open WebUI just didn't call the tool... very odd.

[painapple-nl]

For such a large issue I'm surprised with the lack of activity in this thread. Not sure about the other developers in this thread. But for us, tool-calls are the whole point of using a chat-bot through an interface like open-webui.

[saccodd]

Same problem here. I'm able to chain calls but for some reason the last call is not processed (using gpt-4o, same behavior with default or native function calling)

[tblattner]

I'm having the same issues as everyone using Llama-4-Scout with vllm as the backend. Query sent to tool, only responds with the tool output. Query + tool output doesn't appear to be sent to the LLM

OpenWebUI version: 0.6.15

Native tool calling enabled via these parameters:

--enable-auto-tool-choice --tool-call-parser llama4_pythonic --chat-template /path/to/tool_chat_template_llama4_pythonic.jinja

In case it helps, here is the chat template: https://github.com/vllm-project/vllm/blob/main/examples/tool_chat_template_llama4_pythonic.jinja

Edit: Digging into the code a little...

Unless I'm missing something, it appears it may only call the LLM once when native tool calling is enabled? I feel like the workflow should be identical to the default non-native, but without the non-native chat template. Because it should fill in the payload with tool info. At least that's how I think it should work. But happy to be wrong here.

open-webui/backend/open_webui/utils/middleware.py

Line 901 in b5f4c85

if metadata.get("function_calling") == "native":

[snpszhw]

I don't think this issue should be resolved by a refined prompt, this is obviously a logic bug internally.

[painapple-nl]

This has caused me to switch away from open webui - tooluse is the most valueable feature of modern LLMs.

[RodolfoCastanheira]

Oh, what are you using now?

…

On Sun, Jul 13, 2025, 10:44 a.m. pAinapple ***@***.***> wrote: This has caused me to switch away from open webui - tooluse is the most valueable feature of modern LLMs. — Reply to this email directly, view it on GitHub <#9435 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVGHUCPGHY37CRDMMZCUA33IJPDFAVCNFSM6AAAAABWXEJ5FOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNZUGM4TSMY> . You are receiving this because you commented.Message ID: ***@***.***>

[painapple-nl]

n8n + telegram seems to work well

[sancelot]

I dont know if it is related, but sometimes I noticed ollama tool was not called.
And this case was happening because ollama llm context was overflowed.
I could notice it only looking at Ollama debug console.

[rgaricano]

Also in ollama v.0.10.0 was a couple of fixes about tools parsing...
ollama/ollama#11456
ollama/ollama#11509

[2fst4u]

I'm still getting this on v0.6.18 with gpt5. It clearly goes through the tools, calling them correctly and then it just stops and provides no text output once complete.

[thilob97]

Still getting this on v0.6.34 with GPT OSS 120b

[TomasCaruso10]

Im having the exact same issue, i keep on looking beacuse i cant believe this is not solved. Are really people using open web ui without the most important feature of llms working??

Not workink with any GPT llm.

[LandonStewart]

I went to through the process of creating several MCP servers all streamable etc but Open WebUI drops random tools as if they aren't there. If I only use one MCP server at a time the issue isn't quite as bad but it's still there when I have 10-15 tools in a single MCP server. Using OpenAPI instead seems to work so far but MCP is not reliable in any way whatsoever.

[clang88]

Just wondering (have not experienced this so far) are you using the "native tool calling" or the default tool calling? I've noticed that models behave quite differently depending on what I set there.

[LandonStewart]

"native tool calling" or the default tool calling

Honestly, I'm not sure of the difference or what you mean. It took me longer than I'd like to admit to realize I could click "OpenAPI" and get "MCP" in the external tools modal - so I may have missed some other options?

[clang88]

This is what I meant:

Try switching that to native to see if the results improve.

[d-shehu]

Any updates on this? GPT-OSS 120B on llama.cpp with or without Jinja template doesn't work at all.

So I switched to Kimi K2 using AWS Bedrock and it runs the searches but doesn't produce the expected results.

So far the best results have been using regular web search and GPT-OSS. I'm using MCPO over HTTP and stdio.

[PedroFCM]

I've been hitting this with OpenWebUI + AWS Bedrock via REST API. After digging into the code, I believe there are two root causes:

1. function_calling value is not passed through

In main.py ~line 1729, the metadata only checks == 'native' and falls back to 'default', ignoring any other configured value:

# Before
'function_calling': (
   'native'
   if (
       form_data.get('params', {}).get('function_calling') == 'native'
       or model_info_params.get('function_calling') == 'native'
   )
   else 'default'
),

# Fix: pass through whatever is configured
'function_calling': (
   form_data.get('params', {}).get('function_calling')
   or model_info_params.get('function_calling')
   or 'default'
),

2. REST API calls have no server-side tool-calling loop

The native tool execution loop is driven by the frontend via WebSocket (session_id). REST API calls (/api/chat/completions without a WebSocket session) never enter that loop - the LLM returns finish_reason: tool_calls, OWUI executes the tools, but never re-invokes the LLM with the results

The fix adds a server-side loop for API calls (no session_id) that executes tools and re-invokes the LLM until finish_reason != 'tool_calls' or CHAT_RESPONSE_MAX_TOOL_CALL_RETRIES is reached.

I've been running both fixes for a couple of days and solved my issues
PR: #23581