Grant Hermes Only the Toolsets Each Workflow Needs
Toolsets are named bundles that determine which actions Hermes can attempt. Every tool belongs to one toolset, while composite and platform bundles assemble those groups for broader scenarios. Choosing the smallest useful set improves clarity and reduces unnecessary access; choosing all because it is convenient does the opposite.[1]
Distinguish the three built-in shapes
A core toolset represents one capability family: file groups file reading and editing, web groups search and extraction, and terminal groups command and process operations. A composite expands several cores for a job, such as debugging, which combines file, terminal, and web capabilities. A platform toolset defines a complete deployment profile, such as hermes-cli, hermes-acp, or the restricted hermes-webhook set.[1]
This distinction matters for least privilege. A research-only session may need web but not terminal. The safe toolset is a read-only research and media-generation bundle without file writes, shell access, or code execution. A coding task may legitimately need file and terminal access, while a webhook-triggered run receives only web search, extraction, vision, and clarification.[1]
Scope access at the closest boundary
For a single CLI session, pass an explicit list:[1]
hermes chat --toolsets web,file,terminalYou can also use a composite such as debugging, or configure a platform bundle in config.yaml. The hermes tools interface manages individual tools per platform and persists those choices. Individual disables are finer-grained than toolsets: a disabled tool stays unavailable even when its parent toolset is enabled.[1]
Prefer a platform baseline for a recurring surface, a per-session list for exceptional work, and individual toggles for a risky action that should remain unavailable inside an otherwise useful bundle. Review both layers; checking only the toolset name can miss an individual override.
Account for dynamic capabilities
Each configured MCP server creates a runtime toolset named mcp-<server>. Plugins can register additional toolsets, and custom_toolsets can group built-in capabilities for a project. These dynamic bundles should receive the same access review as native ones because their contents can change when a server or plugin changes.[1]
The all or * wildcard expands registered built-in, dynamic, and plugin toolsets, but it does not bypass runtime prerequisites. Capability-gated tools still require their backend or credentials. Kanban is deliberately different: its shared-state mutations require explicit opt-in, so the wildcard does not enable it.[1]
Least-privilege checklist
- Define the exact actions the workflow must perform.
- Start with core toolsets instead of
allor*. - Use a platform set only when its full surface is appropriate.
- Review individual tool disables after choosing bundles.
- Inspect every MCP, plugin, and custom toolset included.
- Confirm capability and credential gates before deployment.
Common pitfalls
- Treating a composite name as harmless without reviewing the core sets it expands.
- Assuming
allgrants Kanban access or bypasses missing runtime prerequisites. - Enabling terminal or file writes for a workflow that only needs public research.
- Forgetting that an individual disable overrides enabled toolset membership.
- Trusting an MCP toolset name without inspecting the server's current tools.
Verification
Launch a disposable session with the exact --toolsets list intended for production. Use hermes tools to compare enabled tools with the workflow requirements, and confirm both required tools and deliberate exclusions. Repeat the check in the real platform context because hermes-cli, ACP, webhook, and messaging profiles differ. If MCP or plugin tools are present, verify their generated toolsets separately and retest after server or plugin updates.