ToolCall JSON is printed but not executed, causing workflow to halt

[aitormendez]

Hi! First of all, thank you for this amazing project. I'm using ollmcp with a local model (crisp-im/Qwen3-4B-instruct-rank-3-Q4_K_M) and trying to run a structured EPUB summarization workflow using several MCP tools: ebook.get_epub_toc, ebook.get_epub_chapter_markdown, and filesystem.write_file.

The goal is to generate a Markdown summary per book, including chapter-by-chapter summaries and a general summary at the top. The workflow is clearly defined and step-based. Everything works fine until the assistant prints a ToolCall as JSON, but does not execute it. After that point, the model stops progressing.

---

🔁 Example of where it halts

The assistant outputs this (correct) tool call, but never executes it:

{
  "name": "ebook.get_epub_toc",
  "parameters": {
    "path": "/Volumes/E/Nextcloud/Materiales espirituales/Reveladores/Dios/Conversaciones con Dios 1 (1995).epub"
  }
}

After that, nothing happens. This has happened in two different points of the workflow (once with filesystem.write_file, and once with ebook.get_epub_toc). All tools work perfectly when called directly.

---

✅ Confirmed

• The same tools work when invoked directly from the prompt.
• The JSON is valid.
• The flow starts correctly (the Markdown file is created, and the headers are written).
• I'm using:

ollmcp -j "/Volumes/D/Documentos D/mcp-servers/clients/ollmcp/servers.json" -m "crisp-im/Qwen3-4B-instruct-rank-3-Q4_K_M"

---

🤔 My Hypothesis

• Either the printed JSON prevents ollmcp from executing the tool call,
• or the agent is hallucinating that it’s calling the tool, while it’s actually just printing the JSON.

---

🔪 Repro Steps

1. Use any EPUB file and define a multi-step summarization flow (can share a full example if needed).
2. Ask the assistant to create a summary Markdown with chapter-wise summaries.
3. After 1–2 successful steps, it will print a JSON like above and stop.

---

Would be happy to provide the full Markdown instruction I’m using, and even a video recording if needed.

Let me know if there's any way to debug further or if this behavior is known. Thanks again for your work!

[f4T1H21]

Same here! See I've been trying this with a code indexing mcp server, the results look like exactly what @alitormendez describes.

[jonigl]

Hey @aitormendez @f4T1H21, hope you’re both doing well!

I’m a bit tied up at the moment but I’ll definitely look into this soon.

In the meantime, could you share:

• Operating system & version
• Python version
• ollmcp install method (pip, source clone, Docker, etc.)
• The exact ollmcp version you’re running
• The MCP server(s) and config you’re pointing at
• Any relevant logs or minimal repro steps (e.g. the full instruction template you used)

That info will help me reproduce and troubleshoot the JSON/ToolCall issue.

Thanks so much for reporting this guys! 🙌

[aitormendez]

Thanks for your quick reply! I've been doing further testing, and I'm a bit confused now.

After reproducing the exact same setup and re-running the prompt, the issue I initially reported (tool call JSON not being executed) did not occur the second time. The tool call was executed correctly, and the output returned as expected. I haven’t changed anything in the config or setup, so I’m not sure what caused the original behavior.

This uncertainty is what makes debugging so tricky in this case. I honestly can’t tell whether the issue lies with ollmcp, the model being used, or something about my environment. To add to the difficulty, I’m encountering several additional issues depending on which model I use:

• Some models (e.g. qwen3, and now also llama3.1) generate tool calls with the correct JSON format, but the call is never triggered.
• In some cases, the model proposes a script or hypothetical solution instead of executing the tool as instructed.
• Some models forget what they said earlier in the same session, even after receiving clear instructions and confirmations.
• There's a tendency to misuse the tool parameters, e.g. using epub_path where path is required, or confusing JSON formats.
• Sometimes Unicode characters in file paths are misencoded (e.g. \u2013 instead of -), leading to FileNotFoundError or failure to resolve paths.

All this makes it very hard to determine the true source of the malfunction. Errors are inconsistent across attempts and models, and vary from unexecuted tools to execution with incorrect arguments, or even contradictory behavior.

---

Here’s the information you asked for:

• Operating system & version: macOS 14.4.1 (Apple Silicon – Mac Studio M2)
• Python version: 3.11.9 (managed via pyenv)
• ollmcp install method: Cloned from jonigl/mcp-client-for-ollama, then installed with pip install -e . inside a virtual environment.
• **ollmcp version: 0.16.0
• MCP servers used:

{
  "ebook": {
    "command": "python",
    "args": ["src/ebook_mcp/main.py"],
    "cwd": "/Volumes/D/Documentos D/mcp-servers/servers-de-terceros/ebook-mcp"
  },
  "filesystem": {
    "command": "npx",
    "args": ["tsx", "index.ts", "/Volumes/E", "/Volumes/D"],
    "cwd": "/Volumes/D/Documentos D/mcp-servers/servers-oficiales/src/filesystem"
  }
}

• Model used: multiple — qwen3-4B-instruct-rank-3-Q4_K_M, llama3.1:8b, llama3.2:3b
• Execution method:

ollmcp -j /Volumes/D/Documentos\ D/mcp-servers/clients/ollmcp/servers.json -

I’ll keep testing and report if I can isolate a reproducible pattern, but right now, I’m stuck in a fog of inconsistent model behavior.

[aitormendez]

I’ve done some digging. It seems models running in Ollama don’t execute tools correctly, even when properly integrated as HTTP MCPs. Instead of invoking them, they just repeat the tool call as plain text.

Model behavior is inconsistent, uncooperative, or outright useless.

Cause: Ollama doesn’t yet have a robust tool-calling layer. This was confirmed by an official team member here: ollama/ollama#11135

However, this is under development. According to the Ollama blog (July 2024), they’re already working on:
1. Tool call streaming – triggering tools as soon as they’re detected, not after the full response.
2. Tool choice – ability to force tool usage from the client side (not relying on model discretion).

Also, in this other issue: ollama/ollama#11113, a team member said there is “basic support” already, and that improvements to this agent layer are being prioritized.

Waiting for updates — for now, tool use with Ollama is limited or unreliable.

Useful links:
– ollama/ollama#9680
– ollama/ollama#10870
– https://ollama.com/blog/tool-support

[jonigl]

Hey @aitormendez @f4T1H21 I don't forget about you guys! I still need to find time to look into this.

In the meantime, I want to thank you @aitormendez for the detailed research! 🙌 I really appreciated that 🙂

[j-dimension]

Running into the same issue. This happens with different models, so it's not a model issue. Let's hope the Ollama folks will figure something out.

@jonigl thanks for this great client implementation. I am using Linux and many of the available clients are only available for macOS or Windows.

[jonigl]

Hey guys, hope you’re doing well! 🙌 @aitormendez @j-dimension @f4T1H21

I tried to reproduce this and found a path that almost always broke with the No content response received. message.

Setup

• Model: qwen3:0.6b (FWIW, smaller models seem more prone to this)

• Tooling: [playwright-mcp](https://github.com/microsoft/playwright-mcp)

• Prompt:

  use tool browser_snapshot https://www.youtube.com/ timeout 20
  

Before vs After

• Before upgrading, that prompt failed consistently with No content response received.
• After upgrading to ollama v0.11.7, it almost never fails. I tried several times; only the last attempt reproduced it (took ~7 tries to catch it on recording).

Asciinema (multiple attempts; last one fails):

Debug notes

• When I hit the consistent failure path, I used conditional breakpoints to watch exactly where the stream stopped. What I saw was that the model finished with a thinking message, but instead of continuing with a proper content message or a tool call, the stream just stopped and everything halted. That’s what triggered the No content response received. error.

Possible cause

• Looks related to this Ollama issue: Tool call parsing fails if an argument contains a closing brace ollama/ollama#12017 and this PR tools: avoid matching braces that are part of tool content ollama/ollama#12039
• Fix appears included in v0.11.7: https://github.com/ollama/ollama/releases/tag/v0.11.7

Could folks here, when you get a chance, try either:

1. Your original repro that used to fail, or
2. The minimal prompt above with playwright-mcp,

on v0.11.6 vs v0.11.7 and share results?

If you can include: Ollama version, model, OS, tool server(s), and any stderr/log snippets when it fails, that would help confirm this was indeed the upstream bug.

Thank you so much, I really appreciate the help on this! 🙂

[en0ds]

Just want to report that i have the same issue. Calling tools will yield empty answers.

[jonigl]

Hey @en0ds, thanks a lot for reporting this!

When you get a chance, could you please share a few more details, such as your ollmcp and ollama versions, along with the MCP server and tools you’re using? Also, a quick description of your use case for this error would be super helpful so I can try to reproduce it on my end.

Thanks in advance! 🙏

[en0ds]

Hey @jonigl

sorry for the inconvenience., the issue was on my side. I'm really thankful for this project, keep up the good work :)

[aitormendez]

oops, I closed issue by mistake, sorry! Could you please reopen it, @jonigl?

[jonigl]

Hey @jonigl

sorry for the inconvenience., the issue was on my side. I'm really thankful for this project, keep up the good work :)

Hey @en0ds no worries, anytime!

oops, I closed issue by mistake, sorry! Could you please reopen it, @jonigl?

hey @aitormendez sure thing! no worries, I reopen this issue. Greetings!