Every tool the agent can use, its canonical name, and how to restrict an agent's toolbox.
Everything an agent can do it does through a tool, and every tool has one
canonical name. This page is the complete list — these names (and the
toolset group names in bold) are what you use to control an agent's
toolbox.
Entries can name a toolset (files), a single tool (edit_file), or a
trailing-star wildcard (browser_*). Names you know from elsewhere work too:
OpenClaw IDs (exec, read, edit, group:fs) and Hermes toolset names
(file, terminal, clarify) resolve to their memcode equivalents — only
where the meaning maps exactly; a name for a capability memcode doesn't have
is rejected with a message, never silently narrowed. Or just tell
memcode admin: "the support agent gets read and web
tools only, no shell."
Two rules that always hold:
Policy shapes the toolbox; it never loosens safety. Every command from
every remaining tool is still risk-checked, and in gateway mode dangerous
commands are denied outright — an agent with shell enabled still cannot be
talked into a destructive command by a chat message.
A hidden tool fails closed. The model never sees tools outside the
policy, and a call to one is refused even if the model invents it.
Migrating? memcode hermes migrate carries your toolsets/disabled_toolsets
over and memcode claw migrate your tools.allow/deny — entries keep your
original spelling where it resolves here. Tools memcode doesn't have (vision,
image generation, home automation, per-sender overrides) are listed in the
migration notes with what to do instead — never silently dropped, never
pretended.