issue: MCP tool call parsed, but sometimes not executed

[WolframRavenwolf]

Check Existing Issues

• I have searched the existing issues and discussions.
• I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.18

Ollama Version (if applicable)

No response

Operating System

macOS Sequoia

Browser (if applicable)

Chrome 138.0.7204.158

Confirmation

• I have read and followed all instructions in README.md.
• I am using the latest version of both Open WebUI and Ollama.
• I have included the browser console logs.
• I have included the Docker container logs.
• I have provided every relevant configuration, setting, and environment variable used in my setup.
• I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
• I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
• Start with the initial platform/version/OS and dependencies used,
• Specify exact install/launch/configure commands,
• List URLs visited, user input (incl. example values/emails/passwords if needed),
• Describe all options and toggles enabled or changed,
• Include any files or environmental changes,
• Identify the expected and actual result at each stage,
• Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

I've successfully connected several MCP servers to Open WebUI via mcpo. When the model performs a tool call, the tool executes correctly.

Actual Behavior

When I enable three MCPs (which can vary), and the model attempts a web search (or likely any other tool call, though web search is the easiest to reproduce), the tool call is parsed successfully, as shown in the logs. However, the execution doesn't occur. There's no outgoing request to mcpo; instead, the tool call immediately returns an empty response, while the Executing... symbol continues to spin, even after the response has finished.

Steps to Reproduce

The latest Open WebUI, freshly pulled from ghcr.io/open-webui/open-webui:main, is running locally in a Docker container on my Mac. mcpo (freshly pulled from ghcr.io/open-webui/mcpo:main) is also running in a Docker container as part of the same Compose file and provides several MCP tool servers: mcp-server-time, mcp-searxng, and linear via mcp-remote.

When I enable only mcp-server-time and mcp-searxng, the web search functions correctly, and the tool is called properly. However, once I also enable linear, the web search tool stops being called.

I can replicate this issue with other MCP servers, such as using firecrawl instead of mcp-searxng and notion instead of linear, indicating that it's not specific to any particular MCP server but rather a more general problem.

Logs & Screenshots

When it works: open-webui-success.log

---

When it fails: open-webui-fail.log

The Executing... symbol keeps spinning even after the response is complete. The network tab shows no connections to the mcpo server.

Additional Information

This is a significant obstacle for me right now because I rely on these tools. I'm ready to provide any additional information you need, as I can consistently reproduce the issue.

[rgaricano]

could you provide backend log? (docker logs open-webui) (after executed the question) &
how do you have setted Advan Param Function Calling (in chat right panel & in model setting)? Default or Native?

[WolframRavenwolf]

Hi @rgaricano, thanks for taking a look at this.

I had already attached the backend logs, directly above the screenshots: open-webui-success.log and open-webui-fail.log. Or do you need anything else?

I am using Native Function Calling.

[rgaricano]

Ok, I can't see any relevant thing in logs,
I supose do you use official mcp-lineal, but I can't see it "content" (it's so close), but I saw some compatible...
( I tried to install but I need make a Linear account... )

That servers use search functions, but for other task: search for teams, project, users,... of linear.

As model is setted as Native tool usage, I think that the model allways choose this mcp for do a search.
A workaround is try with Default Function Calling, and see results, and be more explicit in system prompt, indicating to the model how it have to use one tool or another (e.g.: if user ask for websearch use allways the mcp-searxng tool, doesn't matter if other tool have search capacities ...)

[WolframRavenwolf]

The model selects the correct function, as shown in the screenshots, consistently attempting to execute tool_searxng_web_search_post. It also sends the correct parameters, which I can confirm by expanding the tool box. However, the call itself isn't executed; it returns immediately with an empty string and never reaches mcpo or the MCP server behind it - which should happen in any case, no matter which tool is used, since they're all going through mcpo.

So I wonder why the frontend (it's a direct tool call, as far as I know) isn't trying to send anything to mcpo. I've seen similar behavior now that I added the Home Assistant MCP server as well, so it's not just searching that's affected.

[rgaricano]

It show tool_searxng_web_search_post but it launch the request to the search lineal tool, as it is show in backend logs.
Could you try with the workarounds indicated?:
Try with Default Function Calling, and see results, and be more explicit in system prompt, indicating to the model how it have to use one tool or another (e.g.: if user ask for websearch use allways the mcp-searxng tool, doesn't matter if other tool have search capacities ...)
& see how responds

[WolframRavenwolf]

That's weird if it's showing a different tool than the one it requests. Where in the logs did you see it requesting linear instead of searxng? I'd like to troubleshoot this further, but either it's not logging enough or I just can't find it?

[rgaricano]

Sorry Wolfram,
No, forget that I wrote, ...I have some problems reading your fail log, lines too long that block my editor.
What I saw is a lot of 422 in linear mcpserver tools, and a url:/linear in it that probably it's a misconfiguration (I think that it should be http://localhost:8000/linear, I don't know, never used it), recheck config of liner mco, linear-mcp works as it is? alone? is it tested?

the searxng search seem that it's done but with a empty text query, and don't return any results, if this a result of a bad working of linear? is due a incorrect call from model? an error in one tool that block other tools

[WolframRavenwolf]

Yes, it is http://localhost:8000/linear. They're all correctly configured, tested, and generally working fine.

The queries that failed weren't empty, I expanded the Executing boxes and saw the JSON. It's also in the logs:

open-webui  | 2025-07-22 16:36:33.309 | DEBUG    | open_webui.utils.middleware:response_handler:2146 - Parsed args from {"query":"current Minecraft version 2025"} to {'query': 'current Minecraft version 2025'} - {}

open-webui  | 2025-07-22 16:36:35.953 | DEBUG    | open_webui.utils.middleware:response_handler:2146 - Parsed args from {"query":"Minecraft latest version July 2025"} to {'query': 'Minecraft latest version July 2025'} - {}

open-webui  | 2025-07-22 16:36:37.945 | DEBUG    | open_webui.utils.middleware:response_handler:2146 - Parsed args from {"query":"Minecraft Java Edition latest version"} to {'query': 'Minecraft Java Edition latest version'} - {}

open-webui  | 2025-07-22 16:36:41.006 | DEBUG    | open_webui.utils.middleware:response_handler:2146 - Parsed args from {"query":"Minecraft 1.21 latest update"} to {'query': 'Minecraft 1.21 latest update'} - {}

The difference between the failed and successful queries is that in the success-log, each "Parsed args" line by open-webui is followed by a line from mcpo like this:

mcpo        | 2025-07-22 16:32:48,791 - INFO - Calling endpoint: searxng_web_search, with args: {'query': 'current Minecraft version 2025 latest', 'pageno': 1, 'language': 'all', 'safesearch': '0'}

This line is missing from the fail-log, indicating that the tool call never left the browser or at least didn't reach mcpo. Unfortunately I can't find any more information in the logs, to figure out what exactly is going wrong there.

[rgaricano]

I'll do test with mcp-searxng and other tools to try to trace & find the issue, I will inform you with whatever.

[WolframRavenwolf]

Thanks! Here's my complete mcpo configuration for your reference:

config.json

{
  "mcpServers": {
    "time": {
      "command": "uvx",
      "args": ["mcp-server-time"]
    },
    "searxng": {
      "command": "npx",
      "args": ["-y", "mcp-searxng"],
      "env": {
        "SEARXNG_URL": "http://host.docker.internal:8888"
      }
    },
    "firecrawl": {
      "command": "npx",
      "args": ["-y", "firecrawl-mcp"],
      "env": {
        "FIRECRAWL_API_URL": "http://host.docker.internal:3002"
      }
    },
    "home-assistant":{
      "command": "uvx",
      "args": ["mcp-proxy"],
      "env": {
        "SSE_URL": "https://homeassistant/mcp_server/sse",
        "API_ACCESS_TOKEN": "…"
      }
    },
    "linear": {
      "command": "bash",
      "args": ["-c", "npm install --no-save undici@latest >/dev/null 2>&1 && NODE_OPTIONS=--import=/app/heartbeat-patch.mjs npx mcp-remote https://mcp.linear.app/sse 3334 --transport sse-only"]
    },
    "notion": {
      "command": "bash",
      "args": ["-c", "npm install --no-save undici@latest >/dev/null 2>&1 && NODE_OPTIONS=--import=/app/heartbeat-patch.mjs npx mcp-remote https://mcp.notion.com/sse 3334 --transport sse-only"]
    }
  }
}

The bash commands for the SSE servers resolve an issue in mcp-remote that causes SSE timeouts. However, this is unrelated to the current issue, as I have experienced it before and independently of the timeouts.

And here's my tools configuration inside Open WebUI:

[rgaricano]

It took me a while, but I got it installed: time, searxng (locally, without Docker), linear, and notion. I tested it searching for news with searxng, and it worked with and without linear enabled. I've only had a similar issue with the default tool setting (not native), but it asked me to be more specific with the search. I changed it to search for the latest news with searxng, and it performed the search without any issues.
Tomorrow I'll run more thorough tests and post screenshots.

[WolframRavenwolf]

Thank you, I appreciate it! I hope you can uncover what's happening. I'd dive deeper into the investigation myself if I knew where to find more debugging information, such as when and how the function calls are executed and how requests are sent to mcpo. Even in Debug logging mode, I don't see enough information to effectively track this.

[rgaricano]

[rgaricano]

I used a config.json a little more reduced (I’m not using docker), and for avoid some issues:

"mcpServers": {
    "time": {
      "command": "uvx",
      "args": ["mcp-server-time"]
    },
    "searxng": {
      "command": "npx",
      "args": ["-y", "mcp-searxng"],
      "env": {
        "SEARXNG_URL": "https://searxng.torre-nueva.org"
      }
    },
    "linear": {
      "command": "bash",
      "args": ["-c", "npm install --no-save undici@latest >/dev/null 2>&1 &&  npx mcp-remote https://mcp.linear.app/sse 3334 --transport sse-only"]
    },
    "notion": {
      "command": "bash",
      "args": ["-c", "npm install --no-save undici@latest >/dev/null 2>&1 &&  npx mcp-remote https://mcp.notion.com/sse 3334 --transport sse-only"]
    }
  }
}

[WolframRavenwolf]

Ah, I see you're using the server-side MCPs. I'm using the client-side direct tool calls. Could that make a difference?

The main reason I'm not using server-side MCPs (in my single user setup) is that I'd have to toggle MCPs on every time I start a new chat, and the reason I'm using MCPs is to let the AI make the decision when and which tools to use. If only it saved the state of the tool toggles, then that could be an ideal solution.

[rgaricano]

yes, it make difference, client side does the call throught ajax, then the ips have to be public accesible, but I don't think that it's relevant in this case (all ips are accessible for your browser), anyway I'll to test with direct connection too (setting the mcpo in the client...)

And No, I haven't to toggle its in every chat, I have it setted in the model and its appear as activated since first moment.
I will inform you with whatever.

[rgaricano]

Tested with direct connections, running mcpo in client.
I have some issues, first because I have my searxng access down, second because linear doesn't recover list of users, then I check linear and browser (I was logged), and retry, and it recovered, then I launched same question for recover linear users and search... all ok!
(search isn't so accurate!!!)

[WolframRavenwolf]

And No, I haven't to toggle its in every chat, I have it setted in the model and its appear as activated since first moment.

How did you achieve this? I can't add models in the Admin Panel, apparently because I don't use Ollama. However, I successfully added the model in the User Workspace based on an existing OpenRouter model and even selected the tools. Yet, for some reason, I can't select the model to use it: It's neither clickable in the Workspace nor visible in the model dropdown list, even though it's set for public visibility.

Getting this to work would actually be preferable to user-defined tools, as it makes tool use more configurable and flexible.

[rgaricano]

don't you see models in adminSettings/models?

If you don't see models from workspace, check user permissions (admin/settings - groups or defaults)

[WolframRavenwolf]

I've figured it out: I added a direct OpenRouter connection as my user, which is why the user models weren't visible in the admin panel. After adding the connection there, all the models appeared, allowing me to assign the tools.

This solution is actually much better than using user-defined tools! Although we deviated from the original issue, this approach is superior, so thank you for bringing it to my attention.

I'll test this new setup further to see if it also resolves the tool call issues...

[venkivijay]

We are facing the same issue. GPT 4.1 and 4o models are able to identify the correct tool function to call but OpenWebUI never makes the call to localhost (direct tools) regardless of the function calling setting. Direct tools connection testing works though.

A bit about the infra:

• Azure OpenAI is the model provider
• LiteLLM exposes the models from Azure to OpenWebUI
• Redis and WebSockets are enabled

Config file:
config-1753948467095.json

[mitchellj]

Same issue here, manage to identify the correct tool, openwebui shows executing tool ... and the mcpo server never gets a response, sometimes clicking the "regen" button fixes the issue and the tool is called, others it just spins on executing tool and no request is ever fired.

[tan-yong-sheng]

Hi @tjbck and @rgaricano, just for your note for function calling API implementatoin which causes MCP tool call parased but sometimes not executed.

This error does not occur every time. Occasionally, the content field is missing in a tool message when using the OpenAI-compatible function calling API (I’m running this through LiteLLM as the wrapper). When that happens, the API returns the following error:

litellm.BadRequestError: MistralException - {"detail":[{"type":"missing","loc":["body","messages",5,"tool","content"],"msg":"Field required", ... }]} 

For example, missing 'content' parameter on the response output:

❌ Example (invalid, causes your error):
{
"role": "tool",
"tool_call_id": "4CqS6tOj0"
}

✅ Example (valid):
{
"role": "tool",
"tool_call_id": "4CqS6tOj0",
"content": "Tool execution result: { ... }"
}

From what I can see, even though the rest of the API endpoint calls are executed correctly, the missing content field seems to stop the MCP tool from finishing its execution.

Screenshots:

[tan-yong-sheng]

Another scenario where the tool is not executed properly (very similar to the previous case) happens when I use Gemini 2.5 Flash.

In this example, the function calling API returns null for the content field, while the finish_reason is "stop".
(Note: Usually, when finish_reason = "tool", it means the API has returned parameters for function execution, but when finish_reason = "stop", it means the conversation is finished without tool execution.)

---

Not sure whether this originates from LiteLLM or OpenWebUI, but in OpenWebUI we could add logic so that if the API response has a finish_reason of "stop" while the content field is either null or missing, the system should automatically retry/resend the request because that's a malformed output for function calling.

[rgaricano]

@tan-yong-sheng,
In another issue #16966, I(∀Helped)'m sketched out a validator for structured and well-formed tool calls.
Do you think something like this would help with this problem?

[tan-yong-sheng]

Hi @rgaricano , I believe so because I haven't faced that similar problem anymore after the upgrade to v0.6.26 at the time being...

[rgaricano]

ok, I think it was fixed by 30540cb

[tan-yong-sheng]

To @rgaricano ,

However, another issue occurs: after a tool call, the tool call execution might be skipped (as shown in the screenshot below). I believe this also happened in earlier versions, but at that time I wasn’t able to figure out the reason behind it.

After some checking, I found this error:

litellm.BadRequestError: MistralException - {"object":"error","message":"Expected last role User or Tool (or Assistant with prefix True) for serving but got assistant","type":"invalid_request_message_order","param":null,"code":"3230"}

This probably mean the tool call execution are not performing properly in some cases (for example, timeout, etc).

I try to catch why the tool calls execution are sometimes skipped from docker logs, but I hardly find the error logs there.

[tan-yong-sheng]

With Gemini-2.5-Flash, I’ve occasionally noticed that tool calls are being skipped (though this happens less often after the upgrade), especially during <thinking> process. However, I couldn’t find any related error logs in docker compose logs.

After checking LiteLLM, I also noticed that the content field is null for entries like {"role": "tool", "content": null, "tool_id": "<tool_id>"}, which is similar to the Mistral case mentioned above. Which also means the tool execution is also sometimes skipped in gemini-2.5-flash.

---

I have tried several times with openai gpt-5-mini as well (but haven't tried reasoning models like o4-mini), and the tool call execution is very well every time at the time being.

[tan-yong-sheng]

After checking the error logs via docker compose logs -f --tail 100 | grep -i 'error', I believe the issue occurs because the parameters generated by the LLM do not match the data types required by the OpenAPI schema. This mismatch causes the MCP tool execution to fail. It might be helpful to provide a clearer warning for this type of error, so just using a model that supports function calling well. Thanks.

Not sure if I were correct, please feel free to comment.

Below is my logs:
logs-error.txt

---

UPDATED x1:

I found that this happens because my system prompt specifies:
2. Use precise date parameters: start_date and end_date in ISO datetime format only, not relative ranges (e.g., 'd', 'w', 'm', 'past 7 days').

As a result, Gemini keeps adding start_date and end_date parameters to the tool call, even though tavily-mcp doesn’t support them (the correct parameter should be days or time_range). Meanwhile, OpenAI gpt-5-mini follows the OpenAPI schema correctly and doesn’t send invalid parameters.

At the end, I found it's the function calling capability of the LLM model which could potentially result to this case.

---

UPDATED x2:

Weird, in one of my trial, openai gpt-5-mini also give non-exist parameters: start_date and end_date parameters to tavily mcp, and the tool execution did work. At the end, I am still unsure why the tool call execution for gemini and mistral failed previously. I will stop my investigation here.

[0zheermao0]

same issue, open-webui often fails to correctly call tools under native function calling settings, and exceptions can be seen in the network tab. As previously discussed, sometimes no requests are sent at all, while at other times multiple requests are sent. The former causes the model to be unable to call tools, and the latter leads to the response ending abruptly. This makes function calling under native settings almost unusable.

[0zheermao0]

Unfortunately, I didn't find any good solution.

The only way I know to ensure that the mcp is called is abandon the agent effect and switch the function calling to default mode

BTW It seems that keeping the mouse focus on owu can increase the success rate (it may just be my feeling).

[ZeroAct]

@0zheermao0

I investigated why some calls succeed while others fail, and here’s the breakdown (we’re running this on a GPT OSS model):

Successful Case

The model outputs the tool call correctly inside the content field as structured JSON.

Example:

"content": "{\n "tool_calls": [\n {\n "name": "retrieve_documents",\n "parameters": {\n "query": "퇴직급여 규정",\n "top_k": 5\n }\n }\n ]\n}"

This triggers the retrieve_documents call, results are returned, and the final answer is generated as expected.

Failed Case

The content field is empty, while the model puts reasoning into reasoning_content instead.

Example:

"content": "",
"reasoning_content": "We need to answer a user question: ... Let's try using retrieve_documents."

As a result, the tool call isn’t emitted on the first pass.

The model then attempts another round to issue the tool call, but this intermediate reasoning leaks to the user, breaking the flow.

Root Cause

The difference is whether the tool call lands in content (✅ works) or in reasoning_content (❌ fails).
Since the GPT OSS model sometimes routes reasoning into reasoning_content, the downstream logic misses the tool call.

[ZeroAct]

I'm not sure if i can handle it 😅

[0zheermao0]

This might be a possible reason, many reasoning models do tool calling in their reasoning stage, which then leads to tools not being triggered by owu.

In my tests, I used gemini-2.5-flash, which is a reasoning model but does not return reasoning content.

Additionally, in my case, I did not observe network requests from tools being made in the cases of owu call failures, so I am not very sure if the model calling tools in the reasoning stage is the main reason for the failure of tool calls. But solving this problem will undoubtedly make owu's tools calling more stable.

[rgaricano]

the tool call lands in content (✅ works) or in reasoning_content (❌ fails).
I'm not sure if i can handle it 😅

workaround, add this after

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

Line 2233 in 598282c

)

# Add this after line 2233 in the reasoning content processing section in backend/open_webui/utils/middleware.py
if reasoning_content:
    # Check if reasoning content contains tool calls
    try:
        # Look for tool call patterns in reasoning content
        tool_call_pattern = r'"tool_calls":\s*\[(.*?)\]'
        tool_call_match = re.search(tool_call_pattern, reasoning_content, re.DOTALL)

        if tool_call_match:
            try:
                # Extract and parse tool calls from reasoning content
                tool_calls_json = f'[{tool_call_match.group(1)}]'
                reasoning_tool_calls = json.loads(tool_calls_json)

                # Process these tool calls the same way as regular tool calls
                for reasoning_tool_call in reasoning_tool_calls:
                    # Add index if missing
                    if "index" not in reasoning_tool_call:
                        reasoning_tool_call["index"] = len(response_tool_calls)

                    # Ensure proper structure
                    reasoning_tool_call.setdefault("function", {})
                    reasoning_tool_call["function"].setdefault("name", "")
                    reasoning_tool_call["function"].setdefault("arguments", "")

                    response_tool_calls.append(reasoning_tool_call)

            except (json.JSONDecodeError, KeyError) as e:
                log.debug(f"Failed to parse tool calls from reasoning content: {e}")

    except Exception as e:
        log.debug(f"Error processing reasoning content for tool calls: {e}")