Hermes Agent Tools: Enabling Only What You Need

What a “toolset” is

A toolset is a bundle of related tools that Hermes loads as a single unit. Think of web (search, extract, fetch), terminal (shell, processes, workdir), file (read, write, patch), or memory (recall, store). Each toolset is a row in the platform’s registry — your CLI, Telegram bot, Discord bot, and Slack workspace each maintain their own per-platform list of which rows are flipped on.

Disabled toolsets do not appear in the agent’s system prompt and do not cost tokens. Their tool schemas are not in the prompt at all — neither their descriptions nor their argument shapes show up — and the model cannot call them because it doesn’t know they exist. That has three real payoffs: smaller prompts (cheaper runs, more room for conversation), faster responses (fewer tokens to score), and a smaller blast radius if the model decides to act on a wrong assumption. It cannot fire a tool it never saw listed.

The flip side: a tool the agent doesn’t know about is a tool you have to explicitly turn on before the model can reach for it. The discipline is to start narrow and widen only when you actually need a tool — not the other way around.

What’s on this build

This build of Hermes ships 23 built-in toolsets, split across four loose roles. Toolset availability is global; what changes per platform is whether each is enabled.

Core: web (search, scraping), browser (Playwright-driven automation), file (read/write/patch over the workspace), terminal (shell and processes), code_execution (a sandboxed Python runner), vision (image analysis), image_gen (text-to-image via the configured provider), and tts (text-to-speech). Almost every agent session wants at least web and file.

Operator: skills (load SKILL.md files into the prompt), todo (task planning across a long conversation), memory (persistent recall and store across sessions), session_search (recall past sessions), clarify (ask the user back when the prompt is ambiguous), and delegation (spawn subagents for parallel work).

Gateway: cronjob (schedule recurring runs), and the per-platform integrations that are wired through the gateway: Telegram, Discord, Slack, WhatsApp, WhatsApp Cloud. Enabling these on the cli platform is typically a no-op; you enable them on the platform you actually receive messages from.

Advanced (often disabled by default on a clean install): video, video_gen, x_search (X/Twitter search), context_engine, homeassistant, spotify, yuanbao, and computer_use (driver-level mouse/keyboard on macOS, Windows, or Linux — usually left off unless specifically needed). Reach for these one at a time and confirm what they cost before leaving them enabled.

List what you have

The registry lives behind one command:

hermes tools list

You get a table — every built-in toolset, its emoji description, and whether it’s enabled on the cli platform. The same registry exists per platform. To see what Telegram sees:

hermes tools list --platform telegram

Or --platform discord, --platform slack, --platform whatsapp. The --platform flag is hermes tools list’s only option; that’s the whole point — it’s a thin viewer over a per-platform enablement matrix. hermes tools --summary (a sibling flag at the parent tools level) prints just the enabled names per platform for quick eyeballing.

You can also run hermes tools with no subcommand at all: it opens the interactive configuration UI, which is friendlier on a TTY but does exactly the same thing as the commands below.

Enable and disable

Two commands, one positional argument, optionally scoped to a platform:

hermes tools enable terminal
hermes tools disable video_gen
hermes tools enable homeassistant --platform cli

NAME is a toolset name (terminal, web, file, skills, and so on) or, for MCP, a server:tool reference. You can pass multiple names in one call. --platform defaults to cli; pass it explicitly when you’re tuning Telegram, Discord, Slack, or WhatsApp independently.

Changes apply on the next session, not retroactively. An already-running chat has already locked in its toolset list; start a new hermes chat (or wait for your next cron tick) to see the new state. This is the single most common surprise — “I enabled it and nothing happened” means the running session is still using the prior snapshot.

Scope one call with —toolsets

Global enablement is for tools you trust across every session. For “let me try this once” the right tool is the per-invocation flag:

hermes chat -q "List what's in /tmp and tell me the largest file" \
  --toolsets terminal

-t/--toolsets is a comma-separated list — --toolsets terminal,file loads both — and it works on both the top-level hermes command and hermes chat. With it you can spin up an agent with exactly the tools you need for that query, regardless of what’s globally enabled. Under the hood it sets the platform snapshot for that invocation only and leaves the saved per-platform state untouched.

The operator habit is to reach for --toolsets first. Test a new tool, test it inside a tight scope, observe what it costs and what it does, and only then promote it to a global hermes tools enable if it’s worth keeping on the prompt full-time. That order keeps surprises local and makes regressions easy to bisect.

Three habits to adopt

1. Default to the fewest toolsets. On a fresh install, most of what you need is web, file, and terminal. Add more only when a specific task demands them.
2. Use --toolsets per call before promoting. A one-line test with --toolsets homeassistant is cheaper and safer than hermes tools enable homeassistant followed by running the agent for real.
3. Run hermes tools list weekly. Sets drift as you try things out, enable a new platform, or update Hermes. A 10-second check every Friday keeps the prompt surface honest.

What goes wrong

• Typo in the toolset name. --toolsets termial is silently accepted — there’s no warning that it didn’t match anything. Either the model gets no tools at all (and complains it can’t help) or you fall back to the default set. Always re-run hermes tools list immediately after enabling to confirm state.

• --toolsets ignored on a running chat. The flag sets the snapshot for the new invocation. If you typed -t web into a chat that already loaded with terminal,file, the rest of that session keeps what it had. Close and re-launch.

• A tool fires when you didn’t want it. Almost always a sign that a broader toolset was left enabled from an earlier session. Run hermes tools list and trim what’s on. If the agent keeps reaching for a particular tool across sessions, disable at the toolset level rather than per-call — the discipline compounds.

• Helmet fires on CI when the prompt is empty. With --toolsets set but no model provider reachable, Hermes may exit before showing tool errors. Run hermes doctor first if state changes seem unreported.

Verification checklist

#	Command	What it proves
1	hermes tools list	Visible active toolsets
2	hermes tools list --platform telegram	Per-platform view
3	hermes chat -q "What is in /tmp?" --toolsets terminal	Single-tool test
4	hermes tools enable <name> then hermes tools list	State reflected

Sources

• Hermes tools docs
• Hermes CLI commands reference
• ABS companion guide: Picking a Model Provider for Hermes Agent

Last verified: 2026-07-14 against Hermes v0.18.2 (2026.7.7.2) on this VPS. Re-run hermes --version before following a flag whose number may have shifted.