Hermes runs on a server, works on a schedule, and delivers results without anyone in the loop. For that to be useful, web access has to actually work — not just return links that the agent then fails to read.

This guide covers the three layers of web access Hermes provides, what each one does, and how to use them for the kinds of tasks the agent is built for.

• Hermes ships with web_search and web_extract as its two primary web tools, plus a full browser toolset (browser_navigate, browser_snapshot, browser_vision, and seven others) for interactive sessions
• web_search returns titles, URLs, and descriptions — with Firecrawl as the backend, it reads page content and returns markdown instead of snippets
• web_extract fetches a specific URL as markdown; without Firecrawl it falls back to plain HTTP and fails on JS-rendered pages
• Firecrawl is the default backend: set FIRECRAWL_API_KEY in ~/.hermes/.env and both tools route through it automatically
• Firecrawl and Tavily both support crawling; Parallel and Exa do not — Firecrawl is the default and most complete pipeline
• Nous Portal subscribers can use the Tool Gateway to skip provider API keys entirely
• The browser tools handle content that only appears after an interaction — login flows, form submissions, dynamically-rendered tables

For a broader introduction to the agent — installation, memory, and scheduling — see the Hermes Agent guide.

Hermes organizes web access into three distinct tool categories, each with a specific job.

web_search takes a query string and returns up to 5 results by default (the limit parameter goes up to 100). Each result includes a title, URL, and description. With Firecrawl as the backend, the search endpoint reads each page and returns markdown content alongside the metadata. With other providers, the description field is a standard snippet.

web_extract takes a URL and returns the full page content as markdown. Pages under 5,000 characters come back in full; larger pages are LLM-summarized before being returned. Without a configured backend, it makes a plain HTTP request — which fails on JS-rendered pages or anything behind bot protection. With Firecrawl, it routes through real browser rendering automatically.

Browser tools (browser_navigate, browser_snapshot, browser_vision, and seven others) operate on a live browser session. They're the right choice when the content only appears after an interaction: clicking a button, submitting a form, scrolling through paginated results. Multiple cloud backends are supported — Browserbase, Browser Use, Firecrawl, and Camofox for local anti-detection — each with different tradeoffs on cost, stealth, and setup.

The two most common patterns:

• Discover then read: web_search finds the relevant pages, web_extract reads one in full
• Navigate then interact: browser_navigate opens the page, browser_snapshot reads the accessibility tree, follow-up tools click and type

Hermes auto-detects which backend to use from whichever API key is in ~/.hermes/.env. With FIRECRAWL_API_KEY set, both web_search and web_extract route through Firecrawl automatically — no config file changes needed.

# ~/.hermes/.env
FIRECRAWL_API_KEY=fc-YOUR-API-KEY

To confirm what's active:

hermes tools

To pin a specific backend instead of relying on auto-detection, run hermes tools, select Web, and pick from the menu. The four supported backends and their capabilities:

Firecrawl and Tavily both support site-wide crawling. Parallel and Exa don't. All four handle search and single-page extraction.

For a self-hosted Firecrawl instance, set FIRECRAWL_API_URL alongside the API key.

Paid Nous Portal subscribers can skip the provider keys entirely. The Tool Gateway routes web_search and web_extract through Firecrawl on your behalf, billed through your subscription. Image generation, TTS, and browser automation are also available through the same gateway.

To enable it, run hermes model, select Nous Portal, and opt in when the gateway prompt appears. You can also toggle it per-tool via hermes tools by selecting "Nous Subscription" as the provider.

With Firecrawl configured, both web tools behave differently in ways that matter for automation.

For web_search: the request hits Firecrawl's search endpoint, which finds pages and reads their content — returning markdown rather than the short descriptions other providers return. For tasks where the agent needs to synthesize information from multiple sources in one shot, this matters: the content is already there without a follow-up extract call per result.

For web_extract: the request routes through Firecrawl's scrape endpoint with real browser rendering. A JS-heavy product page, a Cloudflare-protected site, a page that requires a cookie click before content renders — these all work correctly through Firecrawl and fail without it. The upgrade is automatic once the API key is set.

For crawling: when the agent needs an entire docs site, all blog posts under a domain, or a structured multi-page resource, it can trigger a crawl job in natural language:

"Crawl the docs.example.com/api section and summarize each endpoint"

Firecrawl maps the site and returns every page under the specified path as markdown. Parallel and Exa don't support crawling; Tavily does and can be used as an alternative if needed.

The most practical advantage of Hermes's web tools isn't a single capability — it's that they run unattended, on a schedule, with no rate limits imposed by the platform.

The built-in cron system lets you set up recurring web tasks from a natural language description:

"Every Monday morning, search for new LLM agent papers published in the past week and send a summary to my Telegram"

The agent creates a cron entry. Every Monday, it runs web_search, compiles the results, and delivers the summary. You don't touch anything between runs.

Some patterns that come up repeatedly:

• Research digests: search a topic on a schedule, summarize findings, deliver via Telegram or email
• Change monitoring: extract a pricing or status page weekly, alert when something changes
• Competitive tracking: crawl a competitor's blog or changelog, surface new content
• Data collection: search for new listings, filings, or posts; extract structured data; write to a file or database

The only limit is your API budget — Hermes doesn't impose daily run caps.

web_search and web_extract cover most research tasks. The browser layer handles the rest: content behind login walls, dynamically-rendered tables, form submissions, paginated results that only appear after a click.

browser_navigate opens a URL in a live browser session and executes JavaScript fully before returning. Use this instead of web_extract when the content you need only appears after the page loads client-side.

browser_snapshot returns the page's accessibility tree — every visible element, link, and input field, each tagged with a ref ID like @e1, @e2. Follow-up browser calls use these IDs to click (browser_click) or type (browser_type). It's a text representation, not a screenshot.

browser_vision takes a screenshot of the current page and analyzes it with the model's vision capability — for pages where the accessibility tree alone doesn't capture what matters: charts, complex table formatting, CAPTCHA challenges, or anything that's meaningful visually but not as plain text.

A typical interaction pattern:

"Go to the SEC EDGAR full-text search, search for filings from [company] in the last 30 days, and extract the filing dates and document types from the results table"

The agent navigates, reads the snapshot to find the search field, types the query, submits, reads the results. Structured data that would never surface through a plain search query.

The full browser toolset includes 10 tools: browser_navigate, browser_snapshot, browser_vision, browser_click, browser_type, browser_scroll, browser_press, browser_back, browser_get_images, and browser_console (for reading JS errors from the live page).

For agents running on a server, switching to a cloud browser backend avoids the need for a local Chromium install. Firecrawl is one option — configured with the same FIRECRAWL_API_KEY already used for web search, via hermes tools → Browser Automation → Firecrawl.

query and limit work across all providers. Backend-specific options:

The query field passes search operators through to the backend when supported — site:, intitle:, filetype:, -term, and "exact phrase" work with Firecrawl and most other backends.

Hermes's web pipeline is designed for agents that run continuously. web_search and web_extract handle the majority of research tasks from one API key, with Firecrawl providing real browser rendering for both. The browser layer handles interactive content. The cron system means any of this runs on a schedule with no involvement between runs.

Setup is minimal: one line in ~/.hermes/.env, and both search and extraction are live.

For the full tool reference, see the Hermes tools docs. For a broader look at what you can build on top — memory, skills, scheduling, and subagents — see the Hermes Agent guide.