Tool Calling Issues w/ Ollama

[noble portal]

I'm running qwen3.5:9b on ollama locally and although I installed skills from clawhub like deep-research-pro (~/.openclaw/skills) which should invoke live web fetching, the model refuses to do tool calling it only responds with training data.
When I test it directly on my ollama machine with a curl command and have tool_choice parameter set to required and asking to run the bash command echo hello it responds with:

{"id":"chatcmpl-370","object":"chat.completion","created":1776733744,"model":"qwen3.5:9b","system_fingerprint":"fp_ollama","choices":[{"index":0,"message":{"role":"assistant","content":"","reasoning":"The user wants me to run a simple bash command: echo hello. This is a straightforward command that will print \"hello\" to stdout.","tool_calls":[{"id":"call_e29c6hw8","index":0,"type":"function","function":{"name":"bash","arguments":"{\"command\":\"echo hello\"}"}}]},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":271,"completion_tokens":58,"total_tokens":329}}

But when I try to prompt it to do deep research in the openclaw tui it doesn't live web fetch.

[analog herald]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[stuck yacht]

What your curl proves is only that Qwen can emit a forced tool call in a tiny test. It does not prove it can handle OpenClaw’s full agent prompt, skill instructions, and tool schema surface.

The 4 most likely issues here are:

1. You configured Ollama via /v1 instead of native Ollama
   This is the big one. OpenClaw docs explicitly warn that http://host:11434/v1 breaks reliable tool calling.
   Use:

   {
     models: {
       providers: {
         ollama: {
           baseUrl: "http://127.0.0.1:11434",
           api: "ollama"
         }
   

       }
     }
   }

Not /v1, not api: "openai-completions" unless you accept flaky tools.

Docs: https://docs.openclaw.ai/providers/ollama

2. You have web_fetch but not web_search
web_fetch is keyless and enabled by default, but deep research usually needs search first.
   If you want key-free search through Ollama, run:

   ollama signin
   

   openclaw configure --section web

Then choose Ollama Web Search.

Docs: https://docs.openclaw.ai/tools/web
https://docs.openclaw.ai/tools/ollama-search

3. The skill was installed, but the session did not refresh
   Skills are snapshotted per session. After installing/updating a skill, start a new session.

   Docs: https://docs.openclaw.ai/tools/skills

4. Qwen 3.5 9B is just not strong enough for OpenClaw’s full tool surface
   This is pretty common. Small local models can pass tiny forced-tool tests, then ignore tools in a real agent loop.
   If you want to keep testing locally, try:

   {
     agents: {
       defaults: {
         experimental: {
           localModelLean: true
         }
       }
     }
   }

That reduces prompt/tool pressure.

Docs: https://docs.openclaw.ai/gateway/local-models
https://docs.openclaw.ai/gateway/troubleshooting

Also, if you use tool allowlists, make sure group:web is allowed.

First thing I’d like from you is:

openclaw --version

And if you can, paste these parts of ~/.openclaw/openclaw.json:

• models.providers.ollama
• tools.web
• tools.allow or tools.profile
• agents.defaults.skills if set

If you paste that, I can usually tell exactly which one it is.

[noble portal]

OpenClaw 2026.4.2

[stuck yacht]

Nice, 2026.4.2 is recent enough. This smells much more like config + model behavior than a version bug.

The biggest clue is your curl result. That response shape is from the OpenAI-compatible Ollama path. If your OpenClaw config is also pointing at .../v1 or using api: "openai-completions", that is very likely the issue.

For OpenClaw + Ollama tools, you want the native Ollama API, like:

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://127.0.0.1:11434",
        api: "ollama"
      }
    }
  }

}

Not:

baseUrl: "http://127.0.0.1:11434/v1"
api: "openai-completions"

Docs: https://docs.openclaw.ai/providers/ollama

Also, two other gotchas:

• deep-research-pro usually needs web_search, not just web_fetch
• after installing a skill, start a new session so the skills snapshot refreshes

Docs: https://docs.openclaw.ai/tools/web
https://docs.openclaw.ai/tools/skills

Can you paste either:

1. your models.providers.ollama block from ~/.openclaw/openclaw.json, or
2. the output of:

openclaw models status

If I had to bet right now, I’d bet you’re on the /v1 path, and Qwen 9B is then being asked to do agentic tool use through the stricter OpenAI-compatible surface, which gets flaky fast.

[noble portal]

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : inference/qwen3.5:9b
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

• inference effective=models.json:u...d | models.json=u...d | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

• none

[stuck yacht]

Yep, I think we found it.

Default : inference/qwen3.5:9b

That means OpenClaw is not using the built-in ollama provider. It is using a custom provider named inference from models.json.

So your direct Ollama curl test and your OpenClaw TUI run are not actually the same path. That explains the mismatch.

Most likely, inference is pointing at Ollama’s OpenAI-compatible /v1 endpoint, which the docs explicitly call out as unreliable for tool calling.

Docs: https://docs.openclaw.ai/providers/ollama

What I’d do

1. Reconfigure to the real Ollama provider:

   openclaw onboard
   

Choose:

• Ollama
• Local only
• base URL http://127.0.0.1:11434

2. Set the model to the native Ollama one:

   openclaw models set ollama/qwen3.5:9b
   

3. Start a new session.

4. Configure actual web search too, since deep research usually needs web_search, not just web_fetch:

   openclaw configure --section web
   

   Then pick:

• Ollama Web Search if you ran ollama signin, or
  • DuckDuckGo / Brave / another provider

Docs: https://docs.openclaw.ai/tools/web
https://docs.openclaw.ai/tools/ollama-search

Important note

Even after fixing the provider, Qwen 3.5 9B may still be flaky for full OpenClaw agent/tool use. Tiny forced tool-call tests are much easier than a real agent run.

If you want, paste the inference provider block from:

~/.openclaw/agents/main/agent/models.json

and I can tell you exactly whether it’s the /v1 problem.

[noble portal]

Yes I had set it up with the /v1 endpoint. I just onboarded again but when I put in my base url http://100.72.178.49:11434 and ollama/qwen3.5:9b as the model it returns
Responses API with tool calling: HTTP 404: 404 page not found | Chat Completions API: HTTP 404: 404 page not found
Please choose a provider/model again.

[stuck yacht]

Ah, that helps. Two things to fix here:

1. For Ollama onboarding, use the raw model ID
   Enter:

   qwen3.5:9b
   

   not:

   ollama/qwen3.5:9b
   

   The docs use raw Ollama IDs for onboarding, then OpenClaw maps that to ollama/<model> later.

2. That URL has to expose native Ollama endpoints
   OpenClaw’s Ollama provider wants the plain Ollama server, which should answer on:

   curl http://100.72.178.49:11434/api/tags
   

   If that returns 404, then that host is not exposing native Ollama correctly to OpenClaw. It may be:

   • a proxy that only exposes /v1
   • the wrong service
   • a reverse proxy rewriting paths

For native Ollama, these should work:

curl http://100.72.178.49:11434/api/tags

curl http://100.72.178.49:11434/api/show -d '{"name":"qwen3.5:9b"}'

If those work, rerun:

• provider: Ollama
• mode: Local only
• base URL: http://100.72.178.49:11434
• model: qwen3.5:9b

Docs: https://docs.openclaw.ai/providers/ollama

So the short version is: no /v1, and no ollama/ prefix in the onboarding model field.

If you paste the output of curl http://100.72.178.49:11434/api/tags, I can tell you immediately whether the network path is the remaining issue.

[noble portal]

Those curl commands work. I should clarify that I'm running ollama on another machine and using its IP (100.72.178.49), so I don''t see Ollama listed as a provider during the onboard so I select Other OpenAI-compatible endpoint

[stuck yacht]

Yep, that’s the missing piece.

If you pick “Other OpenAI-compatible endpoint”, you’re back on the exact path that makes Ollama tool calling flaky. For Ollama, that is the wrong provider choice if you want reliable tools.

Since your Ollama host is remote, I’d skip the interactive picker and use the documented non-interactive Ollama setup instead:

openclaw onboard --non-interactive \
  --auth-choice ollama \
  --custom-base-url "http://100.72.178.49:11434" \
  --custom-model-id "qwen3.5:9b" \
  --accept-risk

A couple of important bits:

• use qwen3.5:9b, not ollama/qwen3.5:9b

• use the raw Ollama URL, no /v1

Docs: https://docs.openclaw.ai/providers/ollama
The exact non-interactive example is here: https://docs.openclaw.ai/cli/onboard

After that, run:

openclaw models status

You want to see:

Default : ollama/qwen3.5:9b

and not inference/qwen3.5:9b.

Then start a new session.

If you want web research, also configure web search separately, because deep-research-style skills usually need web_search, not just web_fetch:

openclaw configure --section web

If you want key-free search through Ollama, the remote Ollama machine also needs:

ollama signin

Docs: https://docs.openclaw.ai/tools/ollama-search

If you run that onboard command and paste the new openclaw models status, I can check the result with you.

[noble portal]

It's defaulting to local host not my 100.72.178.49 remote ip

[stuck yacht]

Yep, that means OpenClaw is still using implicit local Ollama discovery, which defaults to http://127.0.0.1:11434.

For a remote Ollama host, you need an explicit provider entry so it stops falling back to localhost.

Put this in ~/.openclaw/openclaw.json:

{
  models: {
    providers: {
      ollama: {
        apiKey: "ollama-local",
        baseUrl: "http://100.72.178.49:11434",
        api: "ollama"
      }
    }

  },
  agents: {
    defaults: {
      model: {
        primary: "ollama/qwen3.5:9b"
      }
    }
  }
}

Then:

openclaw gateway restart

openclaw models status

You want models status to show:

Default : ollama/qwen3.5:9b

and the Ollama provider, not inference/..., and not localhost.

Then start a new session.

Why this happens:

• no explicit models.providers.ollama.baseUrl → OpenClaw assumes local Ollama at 127.0.0.1:11434
• explicit baseUrl → OpenClaw uses your remote host instead