Hermes driver should expose native web/file tools reliably in managed pods

[mostlydev]

Summary

Hermes pods in Clawdapus can come up without expected native runner tools visible to the agent, specifically web search and coding/file-edit workflows. Source inspection shows Hermes upstream does have these tools, but Clawdapus is not fully wiring the required runtime config/env for them.

Findings

1. Hermes upstream already includes the relevant toolsets

Upstream hermes-agent toolsets for Discord/Slack/Telegram include:

• web_search, web_extract
• terminal, process
• read_file, write_file, patch, search_files
• browser tools and other capability groups

So this is not primarily an upstream lack-of-feature problem.

2. Clawdapus Hermes driver does not pass through Firecrawl env

internal/driver/hermes/config.go currently whitelists a narrow set of env vars into the generated Hermes .env. It does not include:

• FIRECRAWL_API_KEY
• FIRECRAWL_API_URL

Upstream Hermes only registers web_search/web_extract when its web-tool availability check passes, so the driver-side omission can make web tools disappear entirely even though the Hermes messaging presets include them.

3. Driver currently relies on upstream fallback toolset defaults

The generated config.yaml sets only model + terminal config. It does not explicitly set platform_toolsets for Discord/Slack/Telegram, instead relying on Hermes gateway defaults. That is brittle because Clawdapus should compile the intended runtime surface explicitly rather than inheriting whatever the upstream default happens to be at that tag.

4. cllama additive mediation is not the cause

Current cllama additive tool mediation appends managed tools to runner-native tools rather than replacing them, so this issue is not explained by native tools being stripped by the proxy.

Goal

Make Hermes-native tools show up predictably in Clawdapus-managed Hermes pods, especially:

• web search
• file read/write/patch/search
• terminal

Proposed work

1. Add FIRECRAWL_API_KEY and FIRECRAWL_API_URL to the Hermes driver env passthrough allowlist.
2. Materialize explicit platform_toolsets in generated Hermes config.yaml for supported messaging platforms instead of relying on upstream fallback defaults.
3. Add regression tests for generated .env and config.yaml.
4. Preserve current terminal/local backend behavior.

Notes

There is also a small upstream Hermes quirk: the web client supports FIRECRAWL_API_URL without an API key, but the current tool availability check appears to only look for FIRECRAWL_API_KEY. Clawdapus can still improve its side immediately by passing both vars through and making toolset selection explicit.

Open questions

• Whether Clawdapus should also expose optional Hermes capability env such as BROWSERBASE_* through the same allowlist, or keep this issue narrowly focused on the missing web-search path.
• Whether we want a broader Hermes capability compilation layer later, beyond platform_toolsets and env passthrough.

Acceptance

• Hermes services with supported handles get explicit platform toolsets in generated config.
• Hermes .env includes Firecrawl vars when supplied in service environment.
• Regression tests cover the generated runtime config.
• Existing Hermes tests stay green.