#Bundled Skill Weather "tool weather not found" OCControl

1 messages · Page 1 of 1 (latest)

meager edge
#

Testing the bundled weather skill in OpenClaw Control (and Discord). Tool Output "tool weather not found".

I'm testing OpenClaw by running a couple basic tasks, such as the weather skill. I've spent time on the issue but no luck. I also just updated OpenClaw, but nothing.

Let me know if any further information is required. Thanks!

OpenClaw 2026.5.5 on a Mac Mini M1
All weather (and gog) CLI commands work perfectly fine.
weather skill status Ready
(gog skill status Ready)

In OpenClaw Control, if I enter curl -s "wttr.in/Chicago?T", Tool Output box gives me the answer. The actual answer is "The weather forecast for Chicago, Illinois is:
Location: Chicago, Cook County, Illinois, United States of America [41.8755546,-87.6244212]
Follow: @igor_chubin for wttr.in updates

openclaw status & doctor --fix = clear
Skills Status Check
Agent: main

Total: 53
✓ Eligible: 11
✓ Visible to model: 11
✓ Available as command: 10
⏸ Disabled: 42
🚫 Blocked by allowlist: 0
🚫 Excluded by agent allowlist: 0
✗ Missing requirements: 0

What this means:
Eligible: installed and requirements pass; the agent may still exclude it.
Visible to model: the agent can see the skill instructions during normal chat.
Available as command: people, scripts, or cron jobs can call the skill explicitly.

Ready and visible to model:
📦 browser-automation
🎮 discord
🎮 gog
📦 healthcheck
📦 node-connect
📜 session-logs
📦 skill-creator
🪝 taskflow
📥 taskflow-inbox-triage
🎬 video-frames
☔ weather

slow raptorBOT
#

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

thorny hamlet
#

openclaw plugins install weather

Try that.

meager edge
#

Thanks. Taking a look.

meager edge
#

Actually:

#

cmhippyhf2@cmhippy2s-Mac-mini ~ % openclaw skills info weather

🦞 OpenClaw 2026.5.7 (eeef486) — Your task has been queued; your dignity has been deprecated.

☔ weather ✓ Ready

Get current weather, rain, temperature, and forecasts for locations or travel planning.

Details:
Source: openclaw-bundled
Path: /opt/homebrew/lib/node_modules/openclaw/skills/weather/SKILL.md
Homepage: https://wttr.in/:help
Visible to model: yes
Available as command: yes

Requirements:
Binaries: ✓ curl

grand steepleBOT
#

Looks like the “Actually:” follow-up got cut off — send the rest if there was more.

But based on the thread: weather is a skill, not a tool named weather. The bundled weather skill is just instructions that tell the agent to use curl against wttr.in; it does not register an OpenClaw tool called weather. So tool weather not found usually means something is trying to invoke the skill as a tool directly, instead of asking the agent normally or using the skill slash command.

Try these two clean tests:

  1. Start a fresh session (/new in Discord, or a new chat in Control), then ask normally: What’s the weather in Chicago?
  2. If native skill commands are enabled, try: /weather Chicago

Expected path: OpenClaw rewrites that to “Use the weather skill…” and the agent should call exec/curl, not a weather tool.

If it still says tool weather not found, please paste the exact message/prompt you sent and the relevant openclaw logs --follow lines around that request. The skill docs are here: https://docs.openclaw.ai/tools/skills — the key bit is that only skills with command-dispatch: tool + command-tool dispatch directly to tools, and bundled weather doesn’t do that.

meager edge
#

But I can't get the bundled weather skill to work in OpenClaw Control. "tool weather not found"

grand steepleBOT
#

Yep — that output confirms the skill is installed and eligible. The important distinction is:

  • Visible to model: yes = the agent sees the weather instructions.
  • Available as command: yes = /weather ... can invoke the skill path.
  • It still does not mean there is a tool named weather.

So if OCControl is literally attempting a tool call named weather, tool weather not found is expected. The weather skill’s SKILL.md teaches the agent to call curl wttr.in/...; it doesn’t have command-dispatch: tool / command-tool: weather.

What I’d check next:

  1. In the same surface, send /weather London or ask normally: What’s the weather in London?
  2. If that fails, start a fresh session with /new and try again — old sessions can have stale skill snapshots.
  3. If the error persists, grab logs around the request with:
    openclaw logs --follow
    
#

If you’re wiring this from OCControl as a direct tool invocation, the fix is to send it as user text / skill command, not as tool: weather. 🦞

#

Got it — in OpenClaw Control, don’t invoke weather from the tools/tool-call path. That path expects an actual OpenClaw tool, and there is no weather tool.

Use the skill command path instead:

/skill weather London

or just ask normally:

What’s the weather in London?

/weather London may work on Discord/Telegram when native skill commands are registered, but the portable syntax is /skill weather London.

If /skill weather London still returns tool weather not found, then I’d suspect Control is misrouting skill commands as tool invocations or the session has stale command/skill state. Try:

#
/reset soft
/skill weather London

If it still fails after that, please paste the exact Control message you typed plus the nearby openclaw logs --follow output. That would be worth a GitHub issue because skills info weather says the skill is ready and command-visible.

meager edge
#

I'm still getting tool not found in OpenClaw Control even when entering /skill weather London.

grand steepleBOT
#

Ah, that’s a useful datapoint. If /skill weather London in Control still becomes tool weather not found, then this is no longer “skill not installed” — your skills info already proves it’s installed.

Most likely one of these is happening:

  1. Control is sending this through a tool-invocation path, not the normal chat/slash-command path.
  2. The active model is hallucinating a weather tool after reading the weather skill, instead of using exec/curl.
  3. The session has stale skill/tool state and needs a hard fresh session, not just retrying in the same chat.

Try this exact message in a brand-new Control chat/session:

Use the weather skill for London. Do not call a tool named weather. Use exec/curl with wttr.in if you need live weather.

If that works, it’s model/tool-call confusion. If it still says tool weather not found, please run these and paste the relevant output:

#
openclaw --version
openclaw logs --follow

Then send /skill weather London once in Control and copy the log lines around that request.

Also useful from the same Control chat:

/commands
/tools compact

At this point it may be a Control routing bug or a provider/tool-call bug, so logs are the thing that will separate “model invented a missing tool” from “Control routed /skill incorrectly.” If logs confirm that, file it here: https://github.com/openclaw/openclaw/issues

meager edge
#

I actually think it's a misconfiguration on my end, and not a bug. It's a bundled skill, so there's not much to it regarding setting it up.

grand steepleBOT
#

I think you’re right — this smells like config/session routing rather than the bundled skill itself.

For weather, the minimum runtime path is:

weather skill instructions → agent sees them → agent uses exec/curl → wttr.in

So the two misconfigs I’d check first are:

  1. The Control session’s active agent can’t use exec
    If tools.allow is restrictive, make sure it includes exec or a group that contains it. Weather doesn’t need a weather tool; it needs the normal agent tool surface plus exec.

  2. The Control session is attached to a different agent than the one you inspected
    openclaw skills info weather proves the skill exists globally/for the inspected context, but Control may be chatting with another agent that has agents.list[].skills or agents.list[].tools narrowed.

In Control, run these in the same chat where it fails:

#
/tools compact
/commands
/context detail

Look for:

  • exec present in tools
  • weather present in skill commands, or /skill support present
  • active agent id/workspace in /context detail

From terminal, also check your effective config for restrictive knobs:

openclaw config get tools
#
openclaw config get agents

What I’d expect to find: either tools.allow is set and doesn’t include exec, or the Control chat is using an agent with skills: [] / a narrow skills list / narrow tools list.

If you paste the /tools compact + /context detail output, we can probably spot it quickly. 🦞

meager edge
#

/tools compat Available tools

Profile: coding

Built-in tools
cron, edit, exec, process, read, sessions_history, sessions_send, session_status, sessions_list, sessions_spawn, subagents, update_plan, web_fetch, web_search, write, sessions_yield

Connected tools
memory_get (memory-core), memory_search (memory-core)

Use /tools verbose for descriptions.

#

I just pasted /tools compact

grand steepleBOT
#

Nice — paste the output from /tools compact here when Control replies.

If Control immediately gives tool weather not found just from /tools compact, that’s a big clue: slash commands are being routed incorrectly in Control.

If /tools compact works, I’m looking specifically for whether exec appears in the tool list. Weather needs exec/curl; there will not be a weather tool.

meager edge
#

exec does appear.

grand steepleBOT
#

Good — then the curl side is probably not blocked.

Next likely issue: the Control chat’s active agent/session doesn’t have the weather skill in its skill snapshot, even though the bundled skill exists on disk.

Please check these in the same Control chat:

/commands
/context detail

In /commands, look for weather or /skill. In /context detail, look for the active agent id/workspace.

Then from terminal, check the skill for that specific agent:

#
openclaw skills info weather --agent <agent-id-from-context>

If your config has an allowlist like this:

agents: {
  defaults: {
    skills: [ ... ]
  }
}

then weather must be explicitly included. A non-empty agents.*.skills list is restrictive; bundled skills don’t bypass it.

So the fix may be as simple as adding weather to the active agent’s skills list, or removing the restrictive skills allowlist if you want all bundled skills available.

meager edge
#

My agent does not have an allowlist.

grand steepleBOT
#

Okay, then I’d narrow it like this: skill visibility is probably fine, tool surface is fine, so the failure is likely either stale session skill snapshot or model is inventing a weather tool call.

Two checks:

openclaw skills check --agent <your-agent-id>

That should show weather under model-visible/command-visible skills for the exact agent Control uses.

Then in Control, start a totally new chat/session — not just retry in the same one — and send:

What is the weather in London? Use curl/wttr.in, not a weather tool.

If that works, the old session had stale/bad context. If it still says tool weather not found, check the model/provider next. Some non-Anthropic/OpenAI-compatible providers will hallucinate skill names as tool names. The bundled skill tells the model “weather exists as a skill”; a weaker tool-calling model may incorrectly emit tool_use: weather instead of using exec.

#

One more useful diagnostic in Control:

/commands

If /commands lists weather but the run still calls tool weather, that’s model behavior, not skill config.

meager edge
#

"What is the weather in London? Use curl/wttr.in, not a weather tool." Worked in Control.

grand steepleBOT
#

Perfect — that rules out the bundled skill, curl, and exec availability. 🦞

So the problem is the model choosing the wrong action when prompted through the skill command path: it’s interpreting “weather skill” as “call a tool named weather” instead of following the skill instructions and using exec/curl.

Practical fixes:

  1. For now, ask naturally with the guardrail:

    What’s the weather in London? Use curl/wttr.in, not a weather tool.
    
  2. If you want /skill weather London to be reliable, add a local override for the bundled skill with a stronger warning. Copy the bundled skill to:

    ~/.openclaw/skills/weather/SKILL.md
    

    and add near the top:

#
   Important: there is no OpenClaw tool named `weather`. Never call a `weather` tool. Use the `exec` tool to run `curl` against wttr.in.

Managed/local skills override bundled skills.

  1. If this only happens with one provider/model, try the same /skill weather London on a stronger tool-calling model. This is exactly the kind of failure weaker/nonstandard tool-call models produce.

Not really a setup bug — more like the skill instructions are too easy for that model to misread. The local override is the cleanest workaround.

meager edge
#

I don't have a skills directory.

grand steepleBOT
#

That’s okay — it’s normal not to have one yet. You can create the managed override directory yourself.

On your Mac:

mkdir -p ~/.openclaw/skills/weather
cp /opt/homebrew/lib/node_modules/openclaw/skills/weather/SKILL.md ~/.openclaw/skills/weather/SKILL.md

Then edit:

nano ~/.openclaw/skills/weather/SKILL.md

Add this near the top of the instructions section, after the frontmatter:

#
Important: there is no OpenClaw tool named `weather`. Never call a `weather` tool. Use the `exec` tool to run `curl` against wttr.in.

Then start a fresh Control chat/session and try:

/skill weather London

You can verify OpenClaw sees the override with:

openclaw skills info weather

The source/path should now point at ~/.openclaw/skills/weather/SKILL.md instead of the bundled /opt/homebrew/... copy.

meager edge
#

I think the last step you displayed was what really solved the issue in Control. Weather skill now works in Control.

grand steepleBOT
#

Glad that did it! 🎉

So the actual fix was creating the managed skill override path and making Control pick up the local ~/.openclaw/skills/weather/SKILL.md copy. That makes sense: bundled skill existed, but the stronger local instruction stopped the model from trying to call a nonexistent weather tool.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes the workaround for the next person.

meager edge
#

I would like the same behavior when I ask for weather in Discord. Is that possible?

grand steepleBOT
#

Yes — if Discord is using the same OpenClaw Gateway, that ~/.openclaw/skills/weather/SKILL.md managed override should apply there too. Managed skills are shared across agents unless a specific agent has a restrictive skills allowlist.

For Discord, do this:

  1. Start a fresh Discord session/thread context if possible:

    /new
    

    or:

    /reset soft
    
  2. Then ask with the skill command:

    /skill weather London
    
#
  1. Or ask normally, mentioning the bot if the channel requires it:
    What’s the weather in London?
    

If Discord uses a different agent than Control, verify that exact agent sees the override:

openclaw skills info weather --agent <discord-agent-id>

The path should point to:

~/.openclaw/skills/weather/SKILL.md
#

If it still uses the bundled /opt/homebrew/... path, Discord is either on a different machine/Gateway, a different HOME, or a different agent config.