Hermes tools 101: give your AI agent its first hands

Up to now your agent can talk. Useful, but a chat window is not an assistant — it is a conversation. Tools are what change that. A tool lets Hermes actually do something: run a command, read or write a file, search the web, click a button in a browser, remember a fact. This is the bridge from chatbot to agent, and it is the moment the whole thing starts to feel real.

This article assumes you already have Hermes installed and talking to a model. If not, start earlier in the Agentic AI series and come back.

What “tools” actually mean for an agent

Under the hood, a tool is a function the model is allowed to call. The flow is simple and worth understanding, because everything else builds on it:

• You ask for something (“what’s in my downloads folder?”).
• The model decides a tool is needed and picks one, along with the arguments to call it with.
• Hermes runs that tool on your machine and captures the result.
• The result is handed back to the model, which uses it to answer you.

The important shift is that the model is no longer guessing from memory — it is acting on real, current data from your system. That is the entire difference between a chatbot and an agent.

What Hermes ships with out of the box

Hermes does not have a single hard-coded list of abilities. It has a tool registry — roughly 86 built-in tools — grouped into toolsets you can switch on and off. You will see a smaller “60+” number in some overview material; the ~86 figure is the real, code-derived registry. Here are the groups that matter most:

• Terminal & files: terminal, process, read_file, write_file, patch, search_files
• Web: web_search, web_extract
• Browser: browser_navigate, browser_click, browser_type, browser_snapshot, and more
• Agent orchestration: todo, clarify, execute_code, delegate_task
• Memory & recall: memory, session_search
• Automation: cronjob
• Media: vision_analyze, image_generate, text_to_speech
• Skills: skill_view, skill_manage, skills_list

Plus integrations — Home Assistant tools (ha_*) and any MCP server tools, which load dynamically. MCP is a big enough topic that it gets its own article later in the series; for now, just know the built-in registry above is your starting kit.

Toolsets, not a flat list

Those groups are called toolsets, and you enable them per platform (CLI, Telegram, Desktop, and so on). Common toolset names include web, terminal, file, browser, vision, image_gen, memory, cronjob, code_execution, and delegation.

Grouping matters for two reasons: it keeps the agent focused (fewer tools means clearer decisions), and it lets you hand different surfaces different powers — your terminal session can have shell access while your Telegram bot does not.

Turning tools on

There are two ways to control which tools a session gets. The interactive one is easiest to start with:

hermes tools

That opens a per-platform configuration screen where you toggle toolsets on or off. When you want a deliberately narrow session — say, only web and terminal — launch chat with an explicit subset:

hermes chat --toolsets "web,terminal"

Starting narrow is a good habit. Give the agent exactly the tools the task needs and nothing more.

Web search works out of the box — keys are optional

Good news, and a misconception worth clearing up: web_search works on a fresh install with no API keys at all. Hermes ships with a keyless mode that rotates your searches across the free tiers of several providers (Exa, Parallel, Firecrawl, Tavily, Keenable) and falls back to the next whenever one is rate-limited. Out of the box, your agent can already search the web.

You have three ways to power search, in rising order of effort and capability:

• Keyless (the default). Nothing to set up. Free and rate-limited, rotating across providers’ public tiers — ideal for getting started and light use.
• Your own provider key. Set one of EXA_API_KEY, TAVILY_API_KEY, FIRECRAWL_API_KEY, or PARALLEL_API_KEY for higher limits and to pin a specific backend. Worth it if you search heavily or want richer results — with Firecrawl, each hit returns full page markdown instead of a short snippet.
• Nous Portal Tool Gateway. On a paid Portal subscription, search routes through managed Firecrawl with no keys of your own, billed through the subscription. Enable it with hermes model.

So the honest summary is the opposite of a catch: search works immediately, and you add a key only when you want more of it.

Your first “doing” moment

With the terminal and file toolsets enabled, try something small and real:

• “List the files in this folder and tell me which is largest.” — exercises terminal / search_files.
• “Read notes.txt and summarise it in three bullets.” — exercises read_file.
• “Create a file called plan.md with these three headings.” — exercises write_file.

The first time the agent reads a real file off your disk and answers from it, the penny drops. That is an agent.

A safety mindset from day one

Tools act on your actual machine, so treat them with the same respect you would give any program with shell access. A few principles that pay off:

• Start read-only. Get comfortable with read_file and search_files before you hand over write_file, patch, or terminal.
• Enable per surface. Powerful tools belong in your controlled CLI session, not necessarily in a chat bot anyone can message.
• Watch the first runs. Read what the agent proposes before it executes, until you trust a given workflow.

None of this is about fear — it is the same care you would take handing a capable new colleague the keys. Start small, verify, expand.

Where to go next

The built-in registry is only the beginning. Once you’re comfortable with what tools can do, the next step is skills — saved, reusable procedures that teach the agent to do multi-step jobs the same right way every time. After that the series gives it a persistent memory, and later MCP for connecting entirely new tool sets.