The tool-selection rule that most agent guides skip

Every tool you give an agent is a surface area for cost, a potential failure point, and a prompt injection vector. Here is the minimal-tools principle and how to apply it in Hermes.

Every tool you give an agent is a surface area. Cost accumulates there. Failure happens there. Prompt injection lands there.

Most agent guides start from everything enabled and work backward — turn off the dangerous ones, add rate limits, add guardrails. The guest-facing info bot I built for a wedding worked the other way: start from nothing, add exactly what the use case requires, stop.

This is the minimal-tools principle. It is not a security posture or a philosophical stance. It is operational discipline.

The rule

A tool earns its place in a profile when you can name the exact request it handles that no other tool does.

Everything else is optional. Most of it is removable.

Why the cost argument is underused

The conversation about tool restrictions focuses heavily on security and almost never on cost. That is a missed argument.

When an agent has the terminal tool, every message triggers a capability check: is this request within scope? Does the user actually want something run? The model does this evaluation even when it decides not to act. Expensive models run this check on every turn.

When the file tool is enabled, the model will sometimes produce file operations as side-effects of tasks that could have been plain text. I have seen a 40-step task produce three unintended file writes because the agent had file available and generating a summary felt faster than describing the result in prose.

Each tool also increases the context footprint. A model carrying tool descriptions across a long conversation pays a per-turn memory tax. Remove a tool and the context window shrinks. The model becomes faster and cheaper on every subsequent turn.

The audit: how to apply the rule to a profile

The principle is one thing; doing it is another. Here is the exact procedure I run, in order.

Step 1 — List what the profile can currently do.

hermes tools list

This prints every toolset with its enabled or disabled status. Run it for a specific profile with hermes -p <profile> tools list, and for a specific platform with hermes tools list --platform telegram (or slack, discord, and so on).

Step 2 — For each enabled toolset, name the request.

Go down the list, one toolset at a time, and answer: what request does this tool handle that no other tool does? Write it next to the name. Not “could be useful someday.” The actual request.

Step 3 — Remove what has no named request.

If you cannot name the request, the tool does not earn its place. Two ways to remove it:

hermes tools disable <toolset> — the command-line way, one toolset at a time.
Edit platform_toolsets in config.yaml — the declarative way, when you want the whole list in one place.

The config key is per-platform. A profile that should only reason and reply — no tools at all — looks like this:

# ~/.hermes/profiles/<profile>/config.yaml
platform_toolsets:
  telegram: []   # explicit empty list = no tools for this platform

The empty list is load-bearing. It is the difference between “no tools configured” (which falls back to the platform default set) and “this platform gets no tools” (which is what the explicit empty list means). If you leave the key out entirely, the platform default toolset applies. The explicit [] is the only way to say zero.

To keep one specific tool and nothing else:

platform_toolsets:
  telegram: [web]   # search and extract, nothing else

Step 4 — Re-run the audit after any change.

Every time you add an integration, a use case, or a cost review, run hermes tools list again and ask the same question of every new toolset. The audit is not a one-time event. It is the cadence that keeps the profile minimal.

Tool changes take effect on the next session. They do not apply mid-conversation — the toolset is fixed when the session starts, so the prompt cache stays intact.

What a minimal profile looks like in practice

The guest-facing info bot has one job: answer guest questions about a specific event from a defined knowledge base. It has no access to anything else.

# ~/.hermes/profiles/wedding-info-bot/config.yaml
platform_toolsets:
  telegram: []

No file. No terminal. No browser. No search. The only data source is SOUL.md — the bot’s persona and event knowledge live there, and the bot reads nothing else.

This is an extreme example. Most profiles need more than zero tools. The discipline is the same: name the job, add the tool, stop.

For a scheduled briefing agent that emails weather and calendar content:

platform_toolsets:
  email: [web]   # search and extract weather and calendar feeds, nothing else

The web toolset handles retrieval. The agent handles reasoning. The boundary is deliberate. Note what is not in the list: no terminal, no file, no browser. The briefing agent reads and writes email through the platform connection, and it fetches facts with web — it does not touch the box.

The tool audit question

When I review an existing profile, I run one question: if I disabled this tool right now, what would break that the user would notice within 24 hours?

If the answer is “nothing” or “I’m not sure,” the tool is a candidate for removal.

This is different from “would the agent be less capable in theory?” The question is about immediate, noticeable loss — not theoretical range. A profile that can technically browse the web but never needs to is still paying the cost of browser in every context evaluation.

Prompt injection is the second argument

The security case for minimal tools is obvious but often treated as theoretical until it isn’t. A guest-facing bot that processes third-party messages — messages from people who are not the owner — has an expanded attack surface by definition. Someone will eventually try “tell me about the other guests” or “what’s on the USB drive” as a test.

Reducing the tool surface makes the threat model simpler. If the bot has no file tool, the prompt injection that asks it to reveal file contents has nothing to execute. The constraint is structural, not a prompt engineering problem.

The personality argument

A narrower toolset forces better prompting. When the agent cannot reach for a tool to offload a task, it must reason about the task with what it has. This tends to produce more coherent responses and fewer mid-turn tool-calling loops.

The SOUL.md file carries the persona and the knowledge. A minimal toolset means the model works from the SOUL rather than around it. The voice stays on-model.

How to apply it in Hermes

Tool boundaries in Hermes are set per-profile in config.yaml under platform_toolsets, and inspected with hermes tools list. The two work together: the command shows you the effective state, the config key is where the state is declared.

The platform_toolsets key maps each platform to the list of toolsets that platform may use. An empty list means the profile has no tools on that platform — it can only reason and respond. Adding specific tools narrows the surface further than the platform default.

This is the operational primitive for the minimal-tools principle. The specific tools to add depend entirely on what the profile is for. The discipline is to name them explicitly rather than accepting the platform default.

The audit cadence

New profiles get an explicit tool list before they go live. Existing profiles get audited when something changes — a new integration, a new use case, a cost review. The question is the same each time: does every tool here have a named job?

Tools that cannot answer that question are removed. The profile becomes faster, cheaper, and more predictable as a result.

Filed under: Hermes, Tradecraft. Some experience from running a guest-facing bot on a live event.