What Ships by Default
A standard Hermes installation includes 60+ built-in tools, grouped into toolsets you saw referenced in Lesson 7.3. The major categories:
| Category | Example tools | Typical use |
|---|---|---|
| Filesystem | read/write files, search directory trees | Codebase work, document editing |
| Shell / execution | run commands, git operations | Development tasks, diagnostics |
| Web | search, fetch/scrape a URL, browser automation | Research, up-to-date information |
| Code execution | sandboxed Python/JS runner | Data analysis, calculations, quick scripts |
| Media | image generation, text-to-speech, transcription | Content creation, voice interfaces (Module 6) |
| Scheduling | cron-style recurring tasks | Reminders, periodic checks (Lesson 17) |
Inspect what’s currently active in your installation:
hermes tools
The Nous Tool Gateway
Many of the more expensive or rate-limited capabilities, web search, browser automation, image generation, premium TTS, are unified behind the Nous Tool Gateway, accessible with a single Nous Portal subscription rather than five separate provider accounts. This is the tool-layer equivalent of the model-layer convenience Nous Portal offers in Lesson 4.
hermes gateway status # confirm the gateway is reachable and which tools it's serving
Bring-Your-Own-Key Alternatives
If you’d rather not go through the Tool Gateway for a specific capability, or don’t have a Portal subscription, most tool categories have a direct provider option:
# ~/.hermes/.env
FIRECRAWL_API_KEY=... # web scraping, direct
FIRECRAWL_API_URL=... # optional: self-hosted Firecrawl instance
BROWSERBASE_API_KEY=... # browser automation, direct
BROWSERBASE_PROJECT_ID=...
FAL_KEY=... # image generation, direct
ELEVENLABS_API_KEY=... # premium TTS, direct
VOICE_TOOLS_OPENAI_KEY=... # OpenAI TTS as an alternative
This mirrors the model-provider pattern exactly: Tool Gateway is the convenient default, direct keys are the escape hatch when you need a specific provider, want to avoid a subscription, or are running a deployment with strict vendor requirements.
Selectively Enabling Tools for a Deployment
Combine what you learned in subtopic 7.3 with the categories above to scope a deployment tightly. A research-only agent, for instance, has no reason to load code execution or media tools:
agent:
platform_toolsets:
cli: ["web_search", "filesystem"]
disabled_toolsets: ["code_execution", "image_generation", "tts"]
A coding assistant flips that around: filesystem, shell, and code execution enabled, media tools disabled. There is no universally “correct” toolset, the right list is a direct function of what the deployment is actually for, which is also the central question Module 7’s guardrails material returns to.
Exercise: run
hermes tools, pick three tools you don’t recognize, and read their descriptions (this is the same<tools>schema text from Lesson 7.1, just for tools Hermes ships rather than ones you wrote). For one of them, decide whether you’d want it enabled in a public-facing messaging bot (Module 6) or not, and why.