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:
- Install → setup wizard → configure provider → see tool status report (read-only)
- All ~40 tools are in
_HERMES_CORE_TOOLS, mapped into hermes-cli/hermes-telegram/etc.
config.yaml defaults to toolsets: ["hermes-cli"] which means "everything"
- Individual tools vanish if their
check_fn fails (missing API key) — no user choice involved
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
-
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).
-
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.
-
Backward compatibility: Existing users with toolsets: ["hermes-cli"] should keep working (treat as "all enabled"). The new enabled_toolsets key is additive.
-
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.
-
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
-
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
-
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
-
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
-
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
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:
_HERMES_CORE_TOOLS, mapped intohermes-cli/hermes-telegram/etc.config.yamldefaults totoolsets: ["hermes-cli"]which means "everything"check_fnfails (missing API key) — no user choice involvedhermes toolsexists for post-install toggling but most users never discover itThis 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:
After selection, prompt for API keys ONLY for the tools they chose:
Config Storage
Save the user's choice to
config.yaml:Or alternatively, store by toolset:
hermes toolsPost-InstallShould read from and write to the same config, keeping it in sync with the initial selection. Currently
hermes toolshas its ownCONFIGURABLE_TOOLSETSlist — this should become the single source of truth for both setup and post-install configuration.Architecture Notes
Current Files Involved
toolsets.py_HERMES_CORE_TOOLS(all tools), platform toolsets (hermes-clietc.), individual toolset definitionstoolset_distributions.pyhermes_cli/config.pyDEFAULT_CONFIGwithtoolsets: ["hermes-cli"], config load/savehermes_cli/tools_config.pyhermes toolscommand,CONFIGURABLE_TOOLSETS,TOOLSET_ENV_REQUIREMENTS, per-platform togglinghermes_cli/setup.pymodel_tools.pyget_tool_definitions(enabled_toolsets=...)resolves which tools are activecli.pyenabled_toolsetsfrom config, passes toget_tool_definitions()Key Design Decisions
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).
Toolset vs individual tool granularity? The selection should be at the toolset level (e.g., "web" enables both
web_searchandweb_extract), not individual tools. This matches howCONFIGURABLE_TOOLSETSandTOOLSET_ENV_REQUIREMENTSalready work.Backward compatibility: Existing users with
toolsets: ["hermes-cli"]should keep working (treat as "all enabled"). The newenabled_toolsetskey is additive.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.
Per-platform differences:
hermes toolsalready supports per-platform toolset configuration. The initial setup could start with a single global selection and let users refine per-platform later viahermes tools.Implementation Sketch
Add tool selection step to
run_setup_wizard()inhermes_cli/setup.py:Unify with
hermes toolsinhermes_cli/tools_config.py:CONFIGURABLE_TOOLSETSbecomes the single source of truthhermes toolsread/write the same config keyhermes toolsshows current selection and allows changesUpdate
get_tool_definitions()inmodel_tools.py:enabled_toolsetsfrom configUpdate
cli.pyto pass the new config throughReferences
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