Wiki · Features in depth
Tools and toolsets
The agent can only do what it has a tool for. Here is what you get out of the box, how toolsets are switched on and off and what to watch out for.
Tools versus toolsets
The difference is like tools and a toolbox: a tool is one thing, a toolset is the box you take to a job. You decide which boxes the agent gets — and that also decides what it can do.
| Term | What it is | Example |
|---|---|---|
| Tool | One specific ability with a fixed input and output | web_search, read_file, terminal, delegate_task |
| Toolset | A group of tools switched on or off together | web, file, terminal, coding |
| Connection (MCP) | An outside program that brings its own tools | a database, a company system, a third-party tool |
What the agent can do out of the box
A fresh install comes with a broad set of tools. Grouped by area:
| Area | Example tools | What for |
|---|---|---|
| Web | web_search, web_extract | Searching and reading pages |
| Terminal and files | terminal, read_file, patch, process | Working on the server and in files |
| Browser | browser_navigate, browser_snapshot, browser_exec | A real browser where clicking is needed |
| Media | vision_analyze, image_generate, text_to_speech | Looking at an image, making an image or speech |
| Planning and splitting work | todo, clarify, execute_code, delegate_task | Break down a task, ask a question, run a script, hand work to a subagent |
| Memory and history | memory, session_search | Durable notes and searching past conversations |
| Scheduled jobs | cronjob_manage | Jobs that run themselves on a schedule |
Get the exact list any time: hermes tools.
Switching toolsets on and off
When you want the agent to do only what you need, narrow the toolsets. Fewer tools means less room for mistakes and faster answers.
To make it permanent, edit the profile's config.yaml — either list the toolsets you
allow, or list the ones you forbid:
Note: web_search is deliberately not part of the
browser toolset, so disabling the browser does not take web search away from you.
When there are too many tools
With two hundred tools switched on, the model gets lost — every tool description takes up space that your request could use. Hermes solves this with tool search: only a handful of the most used tools stay out, the rest is fetched the moment the agent needs them.
| When it happens | What happens |
|---|---|
| There are many tools (typically over 30) | Some tools move behind search; the agent asks for them by itself |
| Why it helps | Answers are faster and cheaper, the model stays focused |
| When it is wrong | When the agent does one narrow job over and over — then fewer toolsets with search off work better |
In practice: when the agent reaches for a tool you did not expect, check whether it has
more toolsets enabled than you need. Configure it with hermes tools — no hand-editing files.
Where tools run (terminal backends)
As long as the agent runs commands on your server, we call it the "local" backend. It can also run elsewhere — useful when you do not want to give it access to your own system, or when you need an environment your server does not have.
| Backend | When it fits | How to set it |
|---|---|---|
local (default) | Your own server or VPS — simplest and fastest | nothing to configure |
| remote machine over SSH | Working on another machine you already have | credentials in the backend settings |
| container (Docker) | You want to separate what the agent may touch — it sees only the container | terminal.backend in config.yaml |
| cloud sandbox (Modal, Vercel Sandbox) | You have no server and want it to live only for the job | terminal.backend plus credentials |
A container is not a security guarantee by itself: it only protects what the agent cannot reach into. Permissions and command approval are covered on the Security page.
Long jobs and administrator rights
| Situation | How it works |
|---|---|
| A job runs long (backup, copying, watching a log) | The agent starts it in the background and can do other work; it can check the status any time |
A command needs sudo | An interactive session shows a masked password prompt (cached for that session). Passwords are never sent into a container or into chat |
| Passwordless sudo | Runs with no prompt — nothing to fill in |
| The job runs in a subagent | A password prompt cannot be opened there — run that command in the main conversation |
Three pitfalls from our own running systems
| What happened | How to spot it and what to do |
|---|---|
| A tool reported success and nothing happened. The call went through, the output looked fine, the change was nowhere | Do not ask the tool whether it did the job — verify the result somewhere else: in the file, with a database query, with the page's HTTP code. Write the verification into your request |
| A connected tool returned data from another project. The server answered correctly, but from the wrong database (we had two projects and one tool between them) | For outside tools, verify what they are connected to and ask about a specific row you know. When it does not match, fix the connection, not the agent |
Secrets showed up in the output as *** | Hermes masks secrets in output. Never verify one by printing it — the print comes back empty or wrong even when the value is fine. Use it directly inside the command |
Our tips
| Tip | Why |
|---|---|
| Enable only the toolsets you really use | Fewer tools mean faster, more accurate answers |
| Say how the work should be verified | "The page must return 200" or "show me the row from the database" — then nothing can just be claimed |
| When the agent can do everything but nothing well, narrow the scope | A narrow toolset with a clear request beats a pile of tools |
| Test a new connection on something you know | One simple query with an expected answer reveals a bad connection before you build on it |