---
title: Tool Calling
type: concept
status: active
created: 2026-07-22
updated: 2026-07-22
verified_on: 2026-07-22
confidence: high
tags: [concept, tool-calling]
sources: [raw/configs/hermes-config-sanitized.txt]
---

# Tool Calling

## Idea
How Hermes decides to invoke a tool, and — more specifically for this page — how it detects and stops itself when tool use goes wrong (loops, repeated failures).

## How this install implements guardrails
**Verified (`~/.hermes/config.yaml`, `tool_loop_guardrails:`):**
```
warnings_enabled: true
hard_stop_enabled: false
warn_after:
  exact_failure: 2
  same_tool_failure: 3
  idempotent_no_progress: 2
hard_stop_after:
  exact_failure: 5
  same_tool_failure: 8
  idempotent_no_progress: 5
```
- Warnings trigger well before any hard stop (2–3 repeats vs 5–8).
- **`hard_stop_enabled: false`** — Hermes will *warn* about a stuck tool loop but will not currently force-stop itself. That's a deliberate-looking but consequential setting: a genuinely stuck loop only gets a warning, not an automatic halt.

## Why it matters here
This is the mechanism behind [[runbooks/troubleshoot-tool-loop]] — that runbook's "agent loops on one tool" symptom is exactly what `warn_after`/`hard_stop_after` are meant to catch. With hard-stop disabled, a human (or the messaging integrations) is the actual backstop today.

## Related
- [[concepts/persistent-shells]]
- [[runbooks/troubleshoot-tool-loop]]
- [[systems/hermes-agent]]