Skip to content

Feature: Interactive tool selection during initial setup #322

@teknium1

Description

@teknium1

Problem

Currently, all tools are enabled by default and silently deactivated when their API keys are missing. Users never explicitly choose which tools they want. The experience is:

  1. Install → setup wizard → configure provider → see tool status report (read-only)
  2. All ~40 tools are in _HERMES_CORE_TOOLS, mapped into hermes-cli/hermes-telegram/etc.
  3. config.yaml defaults to toolsets: ["hermes-cli"] which means "everything"
  4. Individual tools vanish if their check_fn fails (missing API key) — no user choice involved
  5. hermes tools exists for post-install toggling but most users never discover it

This creates confusion: users don't know what tools are available, which ones they're actually using, or why some aren't working. Tools they'll never use (RL training, browser automation) are technically "enabled" but silently gated.

Desired Experience

During Initial Setup (hermes setup)

After provider configuration, present an interactive tool selection:

⚕ Choose Your Tools

  Core tools (always enabled):
    ✓ Terminal & Processes
    ✓ File Operations  
    ✓ Task Planning (todo)
    ✓ Memory & Session Search
    ✓ Skills
    ✓ Task Delegation

  Optional tools (select with space, enter to confirm):
    [x] 🔍 Web Search & Scraping      (requires FIRECRAWL_API_KEY)
    [ ] 🌐 Browser Automation          (requires BROWSERBASE_API_KEY)
    [x] 👁️  Vision / Image Analysis     (requires OPENROUTER_API_KEY)
    [ ] 🎨 Image Generation            (requires FAL_KEY)
    [ ] 🧠 Mixture of Agents           (requires OPENROUTER_API_KEY)
    [x] 🔊 Text-to-Speech             (free — Edge TTS)
    [ ] ⏰ Cron Jobs
    [ ] ❓ Clarifying Questions
    [ ] 🏠 Home Assistant              (requires HASS_TOKEN)
    [ ] 🧪 RL Training                 (requires TINKER_API_KEY)

After selection, prompt for API keys ONLY for the tools they chose:

  Setting up Web Search & Scraping...
    Get key at: https://firecrawl.dev/
    FIRECRAWL_API_KEY: ****

  Setting up Vision...
    Using existing OPENROUTER_API_KEY ✓

Config Storage

Save the user's choice to config.yaml:

# Instead of just:
toolsets: ["hermes-cli"]

# Store explicit tool selection:
toolsets: ["hermes-cli"]
enabled_tools:
  - terminal
  - file
  - web
  - vision
  - tts
  - skills
  - memory
  - session_search
  - delegation
  - todo
  - code_execution

Or alternatively, store by toolset:

enabled_toolsets:
  - terminal
  - file
  - web
  - vision
  - tts
  - skills
  - memory
  - session_search
  - delegation
  - todo
  - code_execution

hermes tools Post-Install

Should read from and write to the same config, keeping it in sync with the initial selection. Currently hermes tools has its own CONFIGURABLE_TOOLSETS list — this should become the single source of truth for both setup and post-install configuration.

Architecture Notes

Current Files Involved

File Role
toolsets.py Defines _HERMES_CORE_TOOLS (all tools), platform toolsets (hermes-cli etc.), individual toolset definitions
toolset_distributions.py Batch/RL data generation only — probabilistic toolset sampling. NOT user-facing, don't change
hermes_cli/config.py DEFAULT_CONFIG with toolsets: ["hermes-cli"], config load/save
hermes_cli/tools_config.py hermes tools command, CONFIGURABLE_TOOLSETS, TOOLSET_ENV_REQUIREMENTS, per-platform toggling
hermes_cli/setup.py Setup wizard — currently shows tool status (read-only), needs selection UI
model_tools.py get_tool_definitions(enabled_toolsets=...) resolves which tools are active
cli.py Reads enabled_toolsets from config, passes to get_tool_definitions()

Key Design Decisions

  1. What's "core" vs "optional"? Some tools should always be on (terminal, file, todo, memory, skills, delegation, code_execution, session_search). Others are optional (web, browser, vision, image_gen, moa, tts, cronjob, clarify, homeassistant, rl).

  2. Toolset vs individual tool granularity? The selection should be at the toolset level (e.g., "web" enables both web_search and web_extract), not individual tools. This matches how CONFIGURABLE_TOOLSETS and TOOLSET_ENV_REQUIREMENTS already work.

  3. Backward compatibility: Existing users with toolsets: ["hermes-cli"] should keep working (treat as "all enabled"). The new enabled_toolsets key is additive.

  4. check_fn still matters: Even if a user enables "web", the tool still needs FIRECRAWL_API_KEY at runtime. The check_fn gating serves as a safety net, but the user's explicit choice controls what's offered and what API keys are prompted for.

  5. Per-platform differences: hermes tools already supports per-platform toolset configuration. The initial setup could start with a single global selection and let users refine per-platform later via hermes tools.

Implementation Sketch

  1. Add tool selection step to run_setup_wizard() in hermes_cli/setup.py:

    • After provider config, show categorized tool list
    • Interactive multi-select (space to toggle, enter to confirm)
    • Prompt API keys only for selected tools
    • Save to config.yaml
  2. Unify with hermes tools in hermes_cli/tools_config.py:

    • CONFIGURABLE_TOOLSETS becomes the single source of truth
    • Both setup wizard and hermes tools read/write the same config key
    • hermes tools shows current selection and allows changes
  3. Update get_tool_definitions() in model_tools.py:

    • Read enabled_toolsets from config
    • Only resolve tools from enabled toolsets (+ always-on core tools)
    • check_fn still applies as safety net
  4. Update cli.py to pass the new config through

References

  • hermes_cli/tools_config.py — existing per-platform tool toggle UI (good reference for the selection UX)
  • hermes_cli/setup.py:280-345 — current tool status display (replace with interactive selection)
  • toolsets.py:228-268 — platform toolset definitions

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions