Academy → Developer guideOfficial documentation · clear explanation

Tools Runtime

الأدوات Runtime

Developer12 minutes3 questions2026-08-09
The idea in one minute

Start with meaning, then move to detail.

This lesson explains Tools Runtime as part of Hermes internals and extension points. You will learn what it does, when it matters, and the smallest safe test that proves it works.

If you are new

If you are new, do not memorize names. Focus on three questions: what problem does this solve, what access does it need, and how can you verify the result?

For hands-on use

For practice, inspect the first example, identify its effects, run it on test data, and compare the result with the source claim.

For specialists

For advanced readers, inspect Tool registration model, How registry.register() works, Discovery: discoverbuiltintools(), then verify failure modes and version compatibility.

What do you need first?

Know Python, Git, and basic project structure before changing code.

What will you know?

A clear outcome before you read.

  • Understand Tools Runtime without assumed prior knowledge.
  • Separate the source description from what still needs testing in your environment.
  • Read the first command and identify its inputs and outputs before copying it.
Lesson terms

Short definitions before the details.

Provider
The service that runs or provides access and authentication to a model.
Tool
A structured action the agent can call to read or change something.
Official page description

Runtime behavior of the tool registry, toolsets, dispatch, and terminal environments

Topic map

What does the source say, and in what order?

  1. 01
    Tool registration model

    Start here to understand the core idea or structure.

  2. 02
    How registry.register() works

    Read this after the foundation, then connect it to the previous step.

  3. 03
    Discovery: discoverbuiltintools()

    Read this after the foundation, then connect it to the previous step.

  4. 04
    Tool availability checking (checkfn)

    Read this after the foundation, then connect it to the previous step.

  5. 05
    Toolset resolution

    Read this after the foundation, then connect it to the previous step.

  6. 06
    How gettooldefinitions() filters tools

    Read this after the foundation, then connect it to the previous step.

  7. 07
    Legacy toolset names

    Read this after the foundation, then connect it to the previous step.

  8. 08
    Dispatch

    Read this after the foundation, then connect it to the previous step.

  9. 09
    Dispatch flow: model toolcall → handler execution

    Read this after the foundation, then connect it to the previous step.

  10. 10
    Error wrapping

    Finish here to verify the result and special cases.

Examples from the official page

Copy only after you understand the effect.

Each call creates a `ToolEntry` stored in the singleton `ToolRegistry._tools` dict keyed by tool name. A registration that would shadow an existing tool from a **different** toolset is rejected (with an error log) unless the caller passes `override=True`; plugin overrides of built-in tools additionally require the operator opt-in `plugins.entries.<plugin_id>.allow_tool_override: true` in `config.yaml`. `schema["description"]` is the authoritative model-facing description. The separate `description=` argument populates `ToolEntry.description`; when it is omitted, the registry metadata falls ba
This auto-discovery means new tool files are picked up automatically — no manual list to maintain. The AST check only matches top-level `registry.register()` calls (not calls inside functions), so helper modules in `tools/` are not imported. Each import triggers the module's `registry.register()` calls. Errors in optional tools (e.g., missing `fal_client` for image generation) are caught and logged — they don't prevent other tools from loading. After core tool discovery, MCP tools and plugin tools are also discovered: 1. **MCP tools** — `tools.mcp_tool.discover_mcp_tools()` reads MCP server
Key behaviors: - Check results are **cached per-call** — if multiple tools share the same `check_fn`, it only runs once. - Exceptions in `check_fn()` are treated as "unavailable" (fail-safe). - The `is_toolset_available()` method checks whether a toolset's `check_fn` passes, used for UI display and toolset resolution. ## Toolset resolution Toolsets are named bundles of tools. Hermes resolves them through: - explicit enabled/disabled toolset lists - platform presets (`hermes-cli`, `hermes-telegram`, etc.) - dynamic MCP toolsets - curated special-purpose sets like `hermes-acp` ### How `get_t
Try it now

Read the first command and identify its inputs and outputs before copying it.

Match every command to your installed Hermes version, review the files and accounts it can reach, and use non-sensitive data for the first test. If this explanation differs from the source, the official source wins.

Knowledge check

Three decisions before completion.

1. What is the source of truth when “Tools Runtime” changes?
2. What is the best way to apply this lesson?
3. What should happen before a step can modify files or an external account?