What is the issue?

Description:

There are two bugs in how Ollama constructs prompts for Qwen3 when tools are passed via the /api/chat tools parameter. Both bugs are absent when tools are embedded directly in the system prompt with the tools parameter omitted. The bugs are visible in the prompt sent by Ollama to the model runner, which is logged when OLLAMA_DEBUG=2 (the prompt can also be seen by monitoring the runner's TCP socket via tcpdump.)

Bug 1: Tool definitions serialised as Go structs rather than valid JSON

When the tools parameter is used, tool definitions in the model prompt are malformed:

{"type": "function", "function": {get_weather Get the current weather for a city {object [city] {"city":{"type":"string","description":"The name of the city"}}}}

The correct format per the official Qwen3 HuggingFace chat template:

{"type": "function", "function": {"name": "get_weather", "description": "Get the current weather for a city", "parameters": {"type": "object", "properties": {"city": {"type": "string", "description": "The name of the city"}}, "required": ["city"]}}}

The root cause is visible in the Qwen3 modelfile template:

{"type": "function", "function": {{ .Function }}}

The .Function variable is rendered using its default Go struct string representation rather than being serialised as JSON. There is no toJson or equivalent function available in Ollama's template engine to fix this at the modelfile level — it requires a code change in Ollama's Go source.

Bug 2: Assistant tool call content stripped from conversation history

When the tools parameter is used and a conversation history containing previous tool calls is passed to Ollama, those tool calls are automatically stripped from assistant turns before the prompt is sent to the runner.

For example, attempting to pass this conversation history:

<|im_start|>assistant
<tool_call>
{"name": "get_weather", "arguments": {"city": "Paris"}}
</tool_call><|im_end|>
<|im_start|>user
<tool_response>
{"temperature": "14C", "condition": "Clear"}
</tool_response><|im_end|>

Results in the model receiving:

<|im_start|>assistant
<|im_end|>
<|im_start|>user
<tool_response>
{"temperature": "14C", "condition": "Clear"}
</tool_response><|im_end|>

The model therefore has no visibility of its own previous tool calls, only the responses. The stripping occurs upstream of the template renderer in Ollama's context building code and cannot be fixed via the modelfile.

Update: This was a client-side issue — see comments below.

Additional finding: redundant /think//no_think text instructions

Ollama appends /think or /no_think to the model prompt when the think parameter is set. This leaks into conversation history as visible text and the model may comment on it. Per the official Qwen3 chat template, thinking mode is on by default and is switched off by appending <think>\n</think> to the prompt — which Ollama already does correctly. The /think//no_think instructions are irrelevant.

Unlike Bugs 1 and 2, this can be fixed at the modelfile level by removing the following lines from the template:

{{- if and $.IsThinkSet (eq $i $lastUserIdx) }}
   {{- if $.Think -}}
      {{- " "}}/think
   {{- else -}}
      {{- " "}}/no_think
   {{- end -}}
{{- end }}

Workaround Both bugs can be avoided by bypassing the tools parameter and embedding tool definitions directly in the system prompt as JSON strings in the Hermes format, matching the official Qwen3 chat template. Apply the /think//no_think fix via a custom modelfile by removing the redundant text instructions from the template

Relevant log output

OS

Linux

GPU

Nvidia

CPU

Intel

Ollama version

0.17.5

Model

qwen3:8b