hermes - 💡(How to fix) Fix [Bug] enabled_toolsets silently rejects MCP server names — MCP tools absent in cron sessions

Summary

enabled_toolsets in cron jobs silently rejects MCP server-related toolset names, causing all MCP tools to be unavailable in cron sessions. The validation path accepts the values without warning, but the agent's tool registry never includes them. Result: every cron session for an MCP-configured profile runs without MCP tools, even though hermes mcp list shows them enabled and interactive (-z/oneshot) sessions register them correctly.

Environment

• Hermes Agent (recent installation, version detail below)
• Cron jobs created via hermes cron create and the cronjob tool
• MCP servers registered via hermes mcp add <name> --command <bin> --args serve (stdio)
• Affected fleet: 13 Hermes profiles, 40 cron jobs, gbrain MCP server (https://github.com/garrytan/gbrain) on each

What I observed

Across 283 cron sessions sampled, with gbrain MCP enabled on every profile (verified via hermes mcp list showing ✓ enabled, all 57 tools), 0 MCP tool calls occurred — the tools array in session_cron_*.json registered only 19 base tools (browser_*, read_file, terminal, etc.) and zero mcp_* tools.

Same agents in interactive mode (hermes --profile X -z "use gbrain.query …") successfully called mcp_gbrain_query and returned brain content. The bug is specific to the cron path.

Repro

1. Profile with mcp_servers.<name> configured in config.yaml (e.g. gbrain)
2. hermes --profile <p> mcp list → shows <name> all tools enabled
3. hermes --profile <p> tools enable <name>:* --platform cron → reports ✓ Enabled: <name>:*
4. Trigger any cron: hermes --profile <p> cron run <id>
5. Inspect resulting session_cron_*.json → tools array has zero MCP tools

What I tried in enabled_toolsets (all silently rejected)

What actually works

The internal MCP toolset alias is mcp-<name> (registered at tools/mcp_tool.py:~2761 via registry.register_toolset_alias(name, toolset_name)).

Setting enabled_toolsets: ["file", "search", ..., "mcp-<name>"] per-job → MCP tools register correctly. In a 13-agent fleet this brought the cron-session tool count from 19 to ~80, with all mcp_<name>_* tools available.

Why this is a defect

1. hermes tools enable <name>:* --platform cron succeeds and the docs (CLI --help text) state "MCP tools use server:tool notation". A user following the documented path gets silent rejection downstream.
2. validate_toolset() does not warn when given an unknown name — it just returns false. The "⚠️ Unknown toolset" message in model_tools.py::_compute_tool_definitions only fires in non-quiet_mode, which cron sessions don't use.
3. Resulting impact: in a real-world deployment with 13 profiles × 40 cron jobs, agents had skills doctrine telling them to use MCP, MCP servers configured and visible in mcp list, but zero MCP availability in the contexts where 95% of agent runtime occurs (cron). Adoption metrics showed 0% — looked like behavioral failure when it was actually structural.

Suggested fix (one of)

a) validate_toolset() accepts MCP server names and <name>:* patterns directly, mapping them to the internal mcp-<name> alias.

b) Or: the per-platform tools config (hermes tools enable <name>:* --platform cron) writes the resolved mcp-<name> form into platform_toolsets.cron so per-job enabled_toolsets inheritance picks it up.

c) Or: at minimum, emit a clear warning when an enabled_toolsets entry doesn't resolve. Silent rejection here cost ~90 minutes of root-cause time and we only found it by reading the source.

Workaround for affected users

# Set enabled_toolsets per-job in cron/jobs.json to include 'mcp-<server>'
# (NOT '<server>' or '<server>:*'). Restart gateway after editing.
import json, pathlib
p = pathlib.Path("~/.hermes/profiles/<profile>/cron/jobs.json").expanduser()
d = json.loads(p.read_text())
for j in d["jobs"]:
    ts = j.get("enabled_toolsets") or []
    if "mcp-gbrain" not in ts:
        j["enabled_toolsets"] = ts + ["mcp-gbrain"]
p.write_text(json.dumps(d, indent=2))

Then launchctl kickstart -k gui/$UID/ai.hermes.gateway.<profile> (or equivalent).

Additional context

We discovered this while running a fleet adoption audit on 13 agents post gbrain-MCP install. Pre-audit, the assumption was that low gbrain usage reflected behavioral preference (agents reaching for read_file instead of mcp_gbrain_query). The audit data was unambiguous (0 calls / 4,498 tool uses) and pointed us at the wire — not behavior.

We'd file this even with the workaround in hand because in any non-trivial fleet, "MCP tools enabled but never called in cron" is going to be a recurring failure mode and the silent-rejection pattern makes it hard to diagnose without source-level investigation.

Happy to provide the repro JSON, session dumps, or a minimal reproducer outside our specific deployment if useful.