(toolsets) narrow core tool surface to essential narrow waist

[svemyh]

Summary

This PR narrows the default tool surface of Hermes Agent (_HERMES_CORE_TOOLS in toolsets.py) to align with the design philosophy explicitly stated in AGENTS.md:

"The core is a narrow waist; capability lives at the edges. Every model tool we add is sent on every API call, so the bar for a new core tool is high."

The Problem

Currently, 41 tools are included in the default _HERMES_CORE_TOOLS list which is loaded on almost every single conversation turn (CLI, TUI, messaging platforms like Telegram, Discord, Slack, etc.). This includes highly specific or specialized capabilities like:

• Home Assistant automation tools
• Kanban board task-tracking tools
• Text-to-speech engine tools
• Desktop Computer Use drivers

Since these tools are sent to the LLM on every single conversation turn, they significantly bloat the model's schema context, break prompt-caching efficiencies, increase latency, and add unnecessary token expenses for routine operations.

The Solution: An Elegant Cut-Down

This PR prunes the non-essential/specialized tools from _HERMES_CORE_TOOLS to retain only the foundational core (26 tools):

1. Core Workspace Files: read_file, write_file, patch, search_files
2. Execution / Shell: terminal, process, execute_code, delegate_task
3. Core Memory & State: memory, todo, session_search
4. Core Research & Automation: web_search, web_extract, browser_*
5. Human Loop / Interactive: clarify, send_message, cronjob

Moving Capabilities to the Edges (Plugins & Gated Toolsets)

The pruned tools are not lost or deleted! They are already fully defined and easily enabled as specialized/service-gated toolsets:

• Home Assistant: Kept in the homeassistant toolset (exposed only when HASS_TOKEN is configured or explicitly requested).
• Kanban: Kept in the kanban toolset (only active when the profile is spawned as a worker or explicitly enabled).
• Computer Use: Kept in the computer_use toolset.
• Text-to-Speech: Kept in the tts toolset or as a future CLI command.
• Yuanbao / Feishu / Spotify: Kept as dedicated messaging platform plugins.

Verification

All tests in tests/test_toolsets.py pass perfectly, ensuring that the platform consistency invariant (TestToolsetConsistency.test_hermes_platforms_share_core_tools) is maintained and the shared core remains robust (>20 tools).

[teknium1]

Thanks for the focused narrow-waist proposal. The current patch has one compatibility regression that needs resolution before it can be safely salvaged.

Problems

• Removing the ha_* entries breaks the existing HASS_TOKEN auto-enable path. hermes_cli/tools_config.py:1723-1740 derives enabled toolsets from static membership in the platform composite; after this deletion it cannot infer homeassistant. The later HASS_TOKEN handling at hermes_cli/tools_config.py:1767-1775 only removes homeassistant from the default-off set and does not add it.
• The claim that all removed tools reach every model call is broader than the runtime behavior. model_tools.py:444-451 filters through check_fn; HA, Kanban, and computer-use have runtime gates (tools/homeassistant_tool.py:344-346, tools/kanban_tools.py:65-93, tools/computer_use/tool.py:899-912).

Suggested changes

• Preserve and test the HASS_TOKEN resolver contract when moving HA out of the core composite.
• Add behavioral tests for each removed tool's activation path; tests/test_toolsets.py:214-230 currently tests only structural shared-core membership.

Automated hermes-sweeper review.

[teknium1]

Removing these entries breaks the current HASS_TOKEN auto-enable path: _get_platform_tools() infers homeassistant only when its static tools are a subset of the platform composite (hermes_cli/tools_config.py:1723-1740). The later HASS_TOKEN branch only removes homeassistant from default_off; it does not add the toolset. Please preserve that resolver behavior and cover it with a test.