Ollama silently drops tool calls to unlisted functions and returns empty replies

A report published on dev.to documents a quiet failure mode in Ollama: when a model emits a tool call whose function name is not in the request's tools list, Ollama discards the call and returns an empty response. No error is raised, nothing is logged, and the token count shows the model generated output that the caller never receives.

The symptom

The test used Ollama 0.40.8, taken from the GitHub release and running on CPU inside a disposable LXC container, with qwen3:0.6b from the Ollama library. The system prompt told the model to call lookup_order for any order question and never answer from memory, while the tools list held only get_time. Across eight runs (seeds 0 to 7, temperature 0.7), every reply came back empty: an empty content string, no tool_calls field, and an eval_count of 25. Adding lookup_order to the tools list flipped the result — all eight replies then contained the call. The OpenAI-compatible endpoint behaved identically, returning finish_reason "stop" with empty content and tool_calls set to null.

The model did generate the call

To see what the model actually produced, the same conversation was sent to /api/generate in raw mode, with a prompt written out by hand following the model's template. The output was a complete, well-formed call wrapped in tags, naming lookup_order with order_id 48213 — and it was exactly 25 tokens, matching the eval_count of every empty reply. The model did its job; the call vanished inside Ollama.

What the parser does

According to the dev.to analysis, Ollama's log shows this model's tool calls are handled by the generic, template-based parser, which covers models without a dedicated parser — including the stock qwen3 library entry. In tools/tools.go at v0.40.8, the parser watches the output stream for the template's tool-call tag and, once it appears, buffers everything that follows. It then tries to match the start of that buffer against a name in the request's tools list. An unlisted name matches nothing, no call object is created, and the buffered text — the entire tool call — is neither emitted as a call nor passed through as plain content, so the response ends up empty. That mechanism fits every observation: the tag and call were generated, the tokens were counted, and nothing came out.

Why it goes unnoticed

An empty reply looks like the model's fault. Small models occasionally produce nothing, so clients tend to retry or render a blank answer rather than check whether tokens were generated — only eval_count reveals that output existed. Calling an unlisted function sounds like an edge case, but the report lists several ordinary agent patterns that produce it: tools loaded on demand, a tool named in another tool's description or in the system prompt, a tools list trimmed per request to save context, or a model recalling a tool from earlier in the conversation. The original report came from an app where the unlisted tool was offered on demand; 28 of 32 replays of its real requests returned empty. The server side offers no hint either: no warning, no unusual done_reason, no log line about a discarded call.

Workarounds

As of 22 October the upstream issue, ollama/ollama#19187, had drawn no reply and no fix had landed. The practical mitigation is to list every tool the model might name, even before its implementation exists. The reporter found that entries with empty parameter schemas were enough to recover most calls (30 of 32), and in the controlled test, simply listing lookup_order made all eight replies return the call. For apps that load tools lazily, the suggested pattern is to declare the names up front and load the implementation when the call arrives. The report also recommends treating any empty reply paired with an eval_count above zero as a dropped call — log it, and retry with the full tool list. A probe script accompanies the post to run this check against a local server.

Why it matters

Anyone wiring agents into Ollama can hit this without ever seeing an error: the failure is invisible to both client and server, and the model takes the blame. The broader lesson applies to any structured-output layer — ask what happens when the model emits something well formed that is not on the expected list, and confirm the parser has a defined path for it, because silent dropping is the worst outcome: nothing downstream can tell. A second habit is to compare what was generated against what was returned; eval_count next to an empty reply is the entire diagnosis here, and it ships in every response. The post also notes a related gap in llama-server's Responses API, which does the opposite and reports a truncated tool call as complete.