#Tool not found issues

1 messages · Page 1 of 1 (latest)

robust warrenBOT
#

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

brazen sphinxBOT
#

This pattern (tool works, then “Tool not found”, then works again) is very often the model/tool-calling layer, not gateway connectivity.

In particular: kimi-k2.5:cloud via Ollama has an existing bug report for intermittent tool binding failures that looks basically identical to what you’re seeing:

Fastest way to confirm “model vs gateway”

  1. Temporarily switch this session/agent to a known tool-reliable model/provider (even just for a 5-minute test).
  2. If the flakiness disappears immediately → it’s almost certainly the Kimi/Ollama tool-call formatting/streaming glitch, not the gateway tool registry.

If you want to prove it with logs (useful for maintainers)

Follow the troubleshooting command ladder and capture logs while reproducing:

Specifically, run:

  • openclaw logs --follow (then trigger the failure)
  • openclaw doctor
  • openclaw status --deep
#

And paste:

  • the exact “Tool not found …” line (does it name read/exec, or some hallucinated tool like file_read?)
  • ~30-50 lines of gateway logs around the failure

One related-but-different bug to watch for

If you ever hit the variant where ALL tools are unavailable after a gateway restart (not intermittent), that matches this other issue:

If you can share the exact error text (including the tool name it says is missing), I can tell pretty quickly which bucket you’re in.

#

“Elevated perms / skipping approvals” isn’t what fixes this.

Elevated is exec-only. It does not grant additional tools (it only changes where/how exec runs when sandboxed). Docs say it pretty explicitly: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

So if you’re getting Tool not found for write/edit/message/session_status/etc, that’s almost certainly one of these:

  1. Tool policy / sandbox policy is hiding tools from the model (so the model tries anyway → runtime says “Tool not found”)
  2. Kimi/Ollama tool-calling is glitching (wrong tool name / malformed tool call / partial tool call), which matches the existing Kimi tool-binding report even if it’s closed: https://github.com/openclaw/openclaw/issues/29965
  3. Less common: a gateway-side registry startup ordering bug (but that’s usually “everything is dead” after restart, cf. https://github.com/openclaw/openclaw/issues/25692)

The “tool test results” your agent printed are also a bit self-contradictory (e.g. claiming browser status when browser itself would have to be callable), which is a classic sign the model is narrating rather than reliably executing tools.

What I’d do next (fast + definitive)

Run this on the gateway host and paste the output:

# 
openclaw sandbox explain --json

That will show the effective:

  • sandbox mode (are Discord channel sessions sandboxed under non-main?)
  • tool profile (tools.profile, per-agent overrides)
  • sandbox tool allow/deny (tools.sandbox.tools.*) if you’re sandboxed
  • any provider-specific restrictions (tools.byProvider["ollama"] or tools.byProvider["ollama/kimi-k2.5:cloud"])

Also paste:

openclaw config get tools

Quick sanity test for “model vs gateway”

Temporarily switch the agent/session to a tool-reliable provider/model (just for a couple minutes). If the “Tool not found” randomness disappears immediately, it’s almost certainly the Kimi/Ollama tool-call layer (not approvals, not WS latency).

#

If you drop the sandbox explain output here, I can point to the exact key that’s causing only read/exec/web_search to be available.

#

That sandbox explain output is actually great news: you’re not sandboxed (mode: off, sessionIsSandboxed: false). So this isn’t a “sandbox jail” / elevated-perms / approvals problem.

Also: elevated won’t help here anyway — elevated only affects exec (where it runs + whether approvals can be skipped). It does not “unlock” write/edit/message/session_status/etc. Docs: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

What “Tool not found” usually means in practice

It’s almost always: the model emitted a tool call with a tool name OpenClaw didn’t advertise for that run (wrong name, wrong casing, or a hallucinated name like file_write, sessionStatus, etc).

That lines up very well with Kimi/Ollama-style “sometimes it follows tool schemas, sometimes it doesn’t”.

Two quick checks that tend to explain the “randomness”

  1. Are you actually staying on the same model, or failing over?
    Run:
openclaw models status
openclaw status --deep

If you have model fallback configured, you can get “random” tool behavior because different providers/models have different tool support/restrictions.

#
  1. Is tool policy restricting what gets sent to Ollama?
    Run and paste:
openclaw config get tools

You’re looking for tools.profile, tools.allow/deny, and especially tools.byProvider entries for ollama or ollama/kimi-k2.5:cloud. (If allow is set, everything else is blocked.)

Docs for tool profiles/policy: https://docs.openclaw.ai/tools

Capturing the smoking gun

If you can, tail logs while reproducing and grab the exact “Tool not found” line (it often includes the tool name the model tried to call):

openclaw logs --follow

(You can also bump verbosity temporarily; docs: https://docs.openclaw.ai/logging)

“If not Kimi 2.5, which Ollama model is better?”

#

I can’t answer that reliably because what’s available + what’s tool-stable changes constantly, and I’ll give you stale/bad advice if I guess. Best path:

  • ask in the server’s #models channel (people there track “tool reliable on Ollama” week-to-week)
  • and/or do a quick A/B: switch to any other Ollama model and re-run a small tool smoke test (10x read, 10x session_status, 10x write) and see if the failure rate drops to ~0.

If you paste openclaw config get tools + openclaw models status, I can tell whether you’re hitting a tool-policy restriction, model failover weirdness, or the Kimi tool-call formatting problem.

#

Yep — there is a #models channel in the OpenClaw Discord (it’s a normal text channel, not the docs forum). If you don’t see it, it’s usually one of:

  • you haven’t enabled it under Server Settings → Channels & Roles → Browse Channels (Discord hides channels you’re not “following” sometimes)
  • you’re missing whatever role/verification step the server uses to unlock all channels

If you truly only see the docs forum, post your question in that forum thread and ask a mod to enable access / point you to #models.

Where to find “most tool-stable local models”

There isn’t a reliable static list (it changes weekly with Ollama versions + model releases), and I’m not going to guess model names and accidentally send you on a wild goose chase.

Best sources:

Practical approach (works better than any list)