Qwen3-Coder 30B on Ollama returns tool calls as plain text instead of executing them

[inyakiporsasalisa]

Before submitting your bug report

• I've tried finding an answer on the Continue docs site
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

## Environment

* Continue: 2.0.0
* VS Code: 1.130.0
* Ollama: 0.32.5
* Model: `qwen3-coder:30b`
* Provider: Ollama
* OS: Windows 10 (VS Code)
* Ollama running in Docker on Linux

## Configuration


models:
  - name: Qwen3 Coder 30B
    provider: ollama
    model: qwen3-coder:30b
    apiBase: http://api.com

Description

Summary

When using Continue 2.0.0 with Ollama 0.32.5 and qwen3-coder:30b, tool calls are returned as plain text instead of being executed by Continue.

To reproduce

Reproduction

Prompt:

Create a file called test.txt with the content hello.

Expected behavior:

Continue should execute the create_new_file tool and create the file.

Actual behavior:

The model responds with:

I'll create a file called test.txt with the content "hello".

<function=create_new_file>
<parameter=filepath> test.txt
<parameter=contents> hello

The tool call is rendered as plain text and is never executed.

Additional information

• ollama show qwen3-coder:30b reports:

Capabilities
  completion
  tools

• The same workflow works correctly with another model (Gemma 4). Continue executes the tool and creates the file successfully.

This suggests a compatibility issue between Continue's tool-calling implementation and qwen3-coder:30b on Ollama.

Log output

[huige66631]

I noticed that the reported response is a textual <function=...> block rather than a structured tool call. Continue currently receives Ollama tool calls separately from ordinary assistant text. A related Qwen3-Coder tool-use request, #6913, was closed as not planned.

I propose adding an Ollama/Qwen tool-call compatibility test that captures the raw /api/chat response, then correcting either request formatting or response normalization at the Ollama-provider boundary, depending on the result.

Would maintainers be interested in accepting a focused PR for this? Does the decision on #6913 still apply, or is there an existing plan or preferred approach?