#is lobster is built in skill, or tool?

1 messages · Page 1 of 1 (latest)

modest kestrel
#

As titled. I want to restrict use of some skills and some tools to certain bots, but I have a hard time identifying which are skills, and which are tools. Case in point: lobster, wacli

floral shaleBOT
molten bluffBOT
#

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

floral shaleBOT
true coralBOT
#

Short answer:

  • lobster = tool
  • wacli = skill

The useful mental model is:

  • Skills teach the model how/when to do something. They live as SKILL.md folders.
  • Tools are actual callable capabilities enforced by tool policy.

So in your examples:

  • wacli exists at skills/wacli/SKILL.md, so it’s a bundled skill
  • lobster is documented as an optional plugin tool and enabled via tools.*, so it’s a tool

How to restrict them per bot/agent:

#
  • Skills: agents.defaults.skills and agents.list[].skills
  • Tools: tools.allow / tools.deny, plus per-agent agents.list[].tools.*

Example:

{
  agents: {
    list: [
      {
        id: "ops",
        skills: ["wacli"],
        tools: { alsoAllow: ["lobster"] }
      },
      {
        id: "chat",
# 
        skills: [],
        tools: { deny: ["lobster"] }
      }
    ]
  }
}

One important nuance: skills are visibility/instruction, not a hard security boundary.
So wacli being hidden as a skill stops it from being advertised to that agent, but if the agent still has broad exec access and the wacli binary is installed, that is a softer restriction than a real tool deny.

Docs:

modest kestrel
#

so let me get this straight: when I do "Allow" under "tools", i am implicitly disallowing other tools not in the list. When I do "alsoAllow", then I enable the tool in addition to other tools that are already available (say because of the profile i have assigned to the agent such as "full"). When I do "deny", then other tools that are implicitly available are STILL available...? Right??

true coralBOT
#

Yep, that’s basically right.

Think of it as:

  1. profile sets the baseline
  2. alsoAllow adds to that baseline
  3. allow replaces the baseline with an explicit allowlist
  4. deny removes tools from whatever is currently allowed
  5. deny always wins

So:

  • allow = “only these tools/groups”
  • alsoAllow = “add these on top of what was already available”
  • deny = “block these, keep the rest”

Example:

# 
{
  tools: {
    profile: "coding",
    alsoAllow: ["lobster"],
    deny: ["browser"]
  }
}

That means:

  • start with coding
  • add lobster
  • remove browser

And yes, with just:

# 
{
  tools: {
    deny: ["exec"]
  }
}

everything else that was otherwise available stays available.

One important gotcha:

  • you cannot set allow and alsoAllow in the same scope
  • so not both under the same tools block, or the same agents.list[].tools block

Tiny nuance:

  • for optional plugin tools like lobster, alsoAllow is often the nicer knob
  • for hard lock-down, use allow
modest kestrel
#

what about skills? any similar operators for skills?

true coralBOT
#

Skills are simpler, and a bit less flexible.

There is no skill-side equivalent of alsoAllow / deny.

The main knobs are:

  • agents.defaults.skills
    default skill allowlist for agents that don’t set their own list

  • agents.list[].skills
    per-agent final skill list, replaces defaults, does not merge

  • agents.list[].skills: []
    no skills for that agent

  • omit agents.defaults.skills entirely
    skills are unrestricted by default

#

Also useful:

  • skills.allowBundled
    global allowlist for bundled skills only
  • skills.entries.<name>.enabled: false
    globally disable a specific skill

So the mental model is:

  • Tools: profile + allow/add/deny
  • Skills: mostly allowlist only

Example:

{
# 
  skills: {
    allowBundled: ["wacli"]
  },
  agents: {
    defaults: {
      skills: ["wacli"]
    },
    list: [
      { id: "bot-a" },              // gets wacli
      { id: "bot-b", skills: [] }   // gets no skills
    ]
  }
}

And if you do:

#

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

modest kestrel
#

while i am at it, what is the clawhub skill? I can install plugins even without the clawhub skill anyway. so just WHAT does this skill do??

true coralBOT
#

Yep, exactly, the clawhub skill is not the thing that gives OpenClaw ClawHub support.

What it does:

  • it is a skill, so it only teaches the agent how to use the external clawhub CLI
  • it does not add a new built-in tool
  • it does not power openclaw skills install or openclaw plugins install

So the split is:

  • Built-in OpenClaw support

    • openclaw skills search/install/update
    • openclaw plugins install/update
    • these work without the clawhub skill

  • clawhub skill

    • teaches the agent commands for the separate clawhub binary
#
  • useful for things like:
    • clawhub login
    • clawhub whoami
    • clawhub sync
    • clawhub skill publish ...
    • direct clawhub search/install/update/list

So in practice, the skill is mainly for registry-authenticated or publisher workflows, not for normal day to day installing.

In other words, the clawhub skill is basically:

“if the clawhub CLI exists, here’s how to use it”

If you never publish/sync skills, you can mostly ignore it, or hide it from agents.

Docs:

#

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

modest kestrel
#

ok explain the "discord" skill to me. I am currently using discord to talk to my agents (all DMs), but I don't even have this skill enabled. I just don't get it.

true coralBOT
#

Yeah, this one is confusing.

The key distinction is:

  • Discord channel support = what lets you talk to the agent on Discord at all
  • discord skill = instructions that teach the agent how to use the message tool for Discord-specific operations

So if you’re already chatting with your agents in Discord DMs, that works because the Discord channel integration is enabled, not because the discord skill is enabled.

What the discord skill actually does:

  • tells the model to use message with channel: "discord"
  • explains Discord-specific actions like:
    • send to another channel/user
    • read/search messages
    • react/pin
    • create threads
    • channel/admin/moderation actions, if those gates are enabled
#

What it does not do:

  • it does not enable Discord itself
  • it does not make normal DM chat work
  • it does not add a separate discord tool

So, in practice:

  • Normal DM conversation with your agent: works without the skill
  • “Go post this in channel X” / “search my server” / “react to that message”: that’s where the skill helps

One more important nuance:

  • hiding/disabling the skill only removes guidance
  • the hard control is still the message tool plus channels.discord.actions.*

So if you want to truly stop an agent from doing Discord ops beyond the current chat, restrict:

  • message tool access
  • and/or channels.discord.actions.*
#

If you want, I can give you the same kind of plain-English breakdown for slack, telegram, and similar skills too.

modest kestrel
#

explain the following bundled skills to me, i want to see if my agents need them or not:

gemini - I mean what? it is an LLM, isn't it? why is it available as a skill? I use google-vertex/gemini-2.5-flash all the time, should i even enable this skill??
github - another confusing skill. i mean I have asked my agent to clone a github repo before, and this was before i even realized there was such a skill available? No currently I do not have it enabled. what does it do??
gog - I will totally be interacting with my google spreadsheets, and my google forms sometime down the road. Will this skill help? If yes, in what way?
healthcheck - I have it enabled currently, but I have zero idea what it does and how it can help me.
himalaya - i imagine i will need it down the road. how do i configure my e-mail credentials etc? and does it keep a full duplicate of my received emails on my server? My email server can be accessed via IMAP.
mcporter - i mean I don't have an MCP server, nor do I even know what an MCP server does. But I will have resources (email server, whatsapp accounts, web site logins, etc) that I want to expose to my agents, ideally without exposing the sensitive PII too such as passwords. Is this skill the way to go?

true coralBOT
#

Big picture first: a lot of bundled skills are just “teach the agent how to use external CLI X”.
They are not the same thing as “OpenClaw needs this to support service Y”.

So for your list:

  • gemini = wrapper for the Gemini CLI
  • github = wrapper for gh
  • gog = wrapper for gog
  • himalaya = wrapper for himalaya
  • mcporter = wrapper for mcporter
  • healthcheck = procedural skill for host/security auditing

gemini

What it is: the external Gemini CLI, not the Google/Vertex model provider itself.

Why it exists as a skill: so the agent can shell out to gemini ... as a separate one-shot tool/CLI workflow.

#

Do you need it if you already use google-vertex/gemini-2.5-flash?
Usually no.

Enable it only if you specifically want:

  • the external Gemini CLI
  • Gemini CLI extensions
  • a side-channel “ask Gemini separately” workflow

If you already use Gemini models through OpenClaw providers, that is unrelated to this skill.

github

What it is: guidance for the GitHub CLI (gh), mainly for:

  • PRs
  • issues
  • Actions / CI logs
  • releases
  • GitHub API queries
#

What it is not: it is not for normal git operations.

So:

  • git clone works fine without the skill
  • the skill helps when you want “check PR 55”, “list failed runs”, “comment on issue 42”, etc.

If you only need repo cloning / local git, you probably do not need it.

gog

Yes, this one will likely help for:

  • Google Sheets
  • Google Docs
  • Gmail
  • Calendar
  • Drive
  • Contacts
#

It requires its own OAuth setup via the gog CLI.

Important nuance:

  • Sheets: yes
  • Docs: yes
  • Forms: not really the way this skill is described

If your Google Form writes responses into a Sheet, then gog becomes very useful, because the agent can read/update the Sheet. But it is not really a “Google Forms management” skill.

healthcheck

This is basically a host hardening / security audit playbook.

It helps with things like:

  • openclaw security audit --deep
  • checking exposure / firewall / SSH posture
  • update status
  • remediation planning
#
  • optionally scheduling periodic audits

Useful if:

  • your gateway runs on a VPS
  • your host is internet-exposed
  • you want help hardening the box

Not especially useful if:

  • you just want app features
  • your setup is local/private and you are not using the agent for host security work

himalaya

This is for email over IMAP/SMTP via the Himalaya CLI.

Config: usually in:

  • ~/.config/himalaya/config.toml
#

You can also run:

  • himalaya account configure

Best practice for credentials:

  • use auth.cmd or keyring
  • avoid raw passwords in plaintext config if possible

Example patterns from the bundled references:

  • backend.auth.cmd = "pass show email/imap"
  • similar for SMTP

Does it keep a full duplicate of your mail on your server?
From the bundled docs, the normal setup is IMAP + SMTP, which means it works against your mail server directly. That is not the same as maintaining a full local duplicate by default.

A separate local mail backend like notmuch is a different thing. So for your IMAP case, I would think of Himalaya as a terminal mail client, not a full mirror/sync engine.

mcporter

#

This one is the most “meta”.

What it is: a CLI for working with MCP servers.

Very roughly, an MCP server is a way to expose capabilities as structured tools to AI clients.

So mcporter helps with:

  • listing MCP servers/tools
  • authenticating to them
  • calling them
  • inspecting schemas
  • generating helper clients

Do you need it right now?
Probably not unless you are explicitly going down the MCP path.

For your examples:

#
  • email server → himalaya is probably simpler
  • WhatsApp accounts → wacli / channel integrations are simpler
  • website logins → browser tooling is usually simpler
  • secret handling / not exposing passwords → MCP can help later, but mcporter itself is not the magic secret-solution

So my practical recommendation:

  1. Do not enable mcporter yet unless you already know you need MCP
  2. Start with direct-purpose skills:
    • gog for Google workspace
    • himalaya for IMAP mail
    • wacli for WhatsApp
  3. Consider MCP later when you want a cleaner custom tool boundary for many services

Also, OpenClaw does support secret-style inputs for MCP server env/config, so MCP can be part of a safer architecture later, but that is more of an advanced setup than a first step.

My practical recommendations for you

#

Probably enable:

  • gog
  • himalaya (when you start email work)

Maybe enable later:

  • github (if you want PR/issues/CI operations)
  • healthcheck (if you care about host hardening / exposed server posture)

Probably skip for now:

  • gemini
  • mcporter

If you want, I can do a second pass and turn this into a simple table:

skill | what it unlocks | should you enable it? | setup burden | risk level

modest kestrel
#

I now have:

  "skills": {
    "entries": {
      "wacli": {
        "enabled": true
      }
    }
  },

suggest changes so the skills i just mentioned are all available, except i want only JUST my cx-redeem agent to have the wacli skill

true coralBOT
#

Yep, do it like this.

skills.entries.*.enabled controls whether the skill is enabled at all.
agents.defaults.skills / agents.list[].skills controls which agents can see it.

So for your case:

{
  skills: {
    entries: {
      gemini: { enabled: true },
      github: { enabled: true },
      gog: { enabled: true },
      healthcheck: { enabled: true },
      himalaya: { enabled: true },
# 
      mcporter: { enabled: true },
      wacli: { enabled: true }
    }
  },

  agents: {
    defaults: {
      skills: ["gemini", "github", "gog", "healthcheck", "himalaya", "mcporter"]
    },
    list: [
      {
        id: "cx-redeem",
        skills: ["gemini", "github", "gog", "healthcheck", "himalaya", "mcporter", "wacli"]
      }
    ]
# 
  }
}

That gives:

  • all agents by default: gemini github gog healthcheck himalaya mcporter
  • only cx-redeem: gets those plus wacli

Two gotchas:

  1. If another agent already has its own agents.list[].skills, that list is final and does not inherit defaults.
  2. If you use skills.allowBundled anywhere, make sure all 7 names are included there too.

Docs:

modest kestrel
#

so... no more allowBundled required?

true coralBOT
#

Correct, you do not need skills.allowBundled unless you want a global bundled-skill allowlist.

So:

  • omit skills.allowBundled → bundled skills are allowed by default
  • then control visibility with:
    • skills.entries.<name>.enabled
    • agents.defaults.skills
    • agents.list[].skills

In your case, that’s enough.

allowBundled only matters if you want to say:

“even if a bundled skill exists, only these specific bundled skills may load at all”

One gotcha:

  • if you already have skills.allowBundled set somewhere, then yes, you must include every bundled skill you want in that list
modest kestrel
#

ok, one of my agents does NOT have wacli skills, but yet it was able to utilize wacli (i saw it using exec to invoke wacli, and it apparently knew the parameters too) to send a test whatsapp message. what gives?

true coralBOT
#

Yep, that behavior is unfortunately expected.

What’s happening:

  • skills are prompt guidance, not a hard permission boundary
  • wacli is just a CLI binary
  • if that agent still has exec access, and wacli is on PATH, it can still run:
    • exec("wacli ...")

So hiding the wacli skill only means:

  • OpenClaw stops advertising that skill to that agent in the skills list/system prompt

It does not mean:

  • “this agent is forbidden from ever invoking the wacli binary”

Why it still knew the flags:

  • the model may already know wacli
#
  • or infer CLI patterns from --help / common conventions
  • or it may have seen it earlier in the same session/context

The docs are pretty explicit on the general rule:

  • skills “teach the agent how and when to use tools”
  • hard enforcement comes from tool policy, exec approvals, sandboxing, and allowlists, not prompt guidance

So the real fix, if you want only cx-redeem to use wacli, is one of these:

  1. Best hard stop: deny exec for agents that should never shell out
  2. Stronger host control: keep exec, but make sure wacli is not available on PATH for those agents/runtimes
  3. Tighter exec policy: use sandbox/exec allowlist controls so only approved commands are runnable
  4. Architectural split: put the WhatsApp-capable agent on a separate gateway/node/runtime

In short:

  • skill restriction = “don’t teach/show it”
#
  • tool/runtime restriction = “actually prevent it”

If you want, paste:

  • openclaw --version
  • the relevant agents.list[] entries
  • the tools / tools.exec section

and I’ll tell you the smallest config change that will stop non-cx-redeem agents from invoking wacli.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.

modest kestrel
#

wrong. I figured it out: by nuking the sessions folder and restarting the gateway, a brand new sessions folder is created for the agent, and in that folder, the sessions.json file no longer lists wacli as one of the skills the agent has.

true coralBOT
#

Yep, you’re right, good catch.

In your case, the problem was stale session state.

OpenClaw snapshots the eligible skills when the session starts and reuses that list for later turns in that same session. So if wacli was present when that session was created, it can stick around in that session metadata until you force a genuinely fresh session. Nuking the agent’s sessions/ dir did exactly that.

So the corrected mental model is:

  • config changed
  • old session kept old skill snapshot
  • fresh session / fresh sessions.json entry dropped wacli

Docs back this up:

#

One nuance still worth keeping in mind:

  • fresh session fixes stale skill visibility
  • but skills are still not the hard security boundary
  • if you need true prevention, that still comes from tool/exec policy

So: I was wrong about the immediate cause here, you were right, this was a stale session snapshot issue.

If this also happens after a normal /new or /reset, that smells bug-worthy and is worth filing here: https://github.com/openclaw/openclaw/issues

Glad you pinned it down. If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.