Local Ollama /v1 models are told to use native tool calls but receive zero schemas

[Ninthkitten]

Prerequisites

• I searched open issues and discussions and did not find an existing report of this bug.
• This is not a security vulnerability.
• I am running the latest code from the dev branch.

Install Method

Docker

Operating System

macOS (Apple Silicon), Docker Desktop

Steps to Reproduce

1. Serve a local model through Ollama's OpenAI-compatible endpoint (/v1) and configure it as a model endpoint.
2. Give the model a task that requires a tool.
3. Inspect the outgoing request payload and the agent-debug line.

Expected Behaviour

Either the model receives native tool schemas, or it is given the text-dialect prompt — the instruction and the payload agree.

Actual Behaviour

They disagree. The schema branch gates on _is_api_model; local Ollama /v1 models fall outside it and receive zero schemas — but they still receive the compact system prompt, which tells them to use native tool calls.

The model is told "use native tool calls", handed no tools, and then does the only thing left: it performs the call as prose. Fabricated invocations, fabricated results, confident summaries of work that never happened.

This is very costly to diagnose, because it presents as a model integrity problem. We retired a local model over "inventing tool receipts" before finding that the environment had handed it an empty toolbox and an instruction to use it.

Logs / Screenshots

[agent-debug] round=1 model=<local model> tools_sent=0

…while the model's reply contains text-shaped tool calls with invented output.

Additional Information

Fix running here: extend the native-schema branch to the Ollama OpenAI-compat path. The first genuine call succeeded immediately:

1 native calls, exit_code=0

Suggested upstream shape: a capability-aware switch — native schemas when the model declares tool support, text dialect otherwise — rather than a hardcoded API/local split. This would build naturally on the capability work proposed in #5575.

Minimum viable improvement even without that: never send the "use native tool calls" prompt on a path that sends no schemas. An empty toolbox with instructions to use it guarantees invented behaviour.

Are you willing to submit a fix?

Yes — the fix described above is running in production here and I can open a PR.

[SteveIDusa]

Confirming this independently — hit the identical symptom over several days (dev branch, commit c80462e) across qwen3.6:27b, qwen3.6:35b, and gemma4:12b via Ollama. Same log signature:

[agent-debug] round=1 model=qwen3.6:35b _is_api_model=False tools_sent=0 tool_names=[] relevant_tools=[...]
[agent-timing] round_start ... tools=0 native_tools=False timeout=300

Matches your diagnosis exactly — relevant_tools was correctly populated by RAG selection, but schemas were never attached. In our case it manifested as the agent looping through the same fabricated multi-step SSH/shell command over and over in raw reasoning text, never converging, which was heavy enough to trigger a browser slowdown warning from the sheer volume of streamed text. +1 for the capability-aware switch proposal over a hardcoded API/local split.