OpenClaw Web Search: Giving Your AI Agent Access to the Internet

If your agent cannot look outside its prompt window, it stays trapped in yesterday's context. That is fine for writing boilerplate. It is terrible for research, monitoring, and anything that depends on current information.

OpenClaw solves that with two separate tools: web_search for finding relevant pages, and web_fetch for pulling readable content from a specific URL. That split matters. Search is for discovery. Fetch is for extraction. Once you understand the difference, your agent stops acting like a chatbot and starts acting like an operator.

This guide is the practical version. I will show you what the tools actually do, how to configure them, where they break, and the patterns that keep them useful instead of noisy. If you also need UI automation after discovery, read my guide to OpenClaw browser automation.

What web_search Actually Does

The web_search tool searches the web using whatever provider you configure in OpenClaw. The docs describe it as a lightweight HTTP tool that returns structured results, not browser automation. So if you want search results with titles, URLs, and snippets, this is the tool.

OpenClaw supports multiple providers for web search, including Brave, DuckDuckGo, Exa, Firecrawl, Gemini, Grok, Kimi, Perplexity, and Tavily. If you explicitly set a provider, OpenClaw uses that provider. If you do not set one, it checks for available API keys in a documented precedence order and uses the first match it finds. That auto-detection order starts with Brave, then Gemini, Grok, Kimi, Perplexity, Firecrawl, and Tavily.

The important operator takeaway is simple: you can wire in a preferred provider, but OpenClaw also has a defined fallback path instead of making you guess what happens when multiple keys exist.

Basic example

await web_search({ query: "OpenClaw plugin SDK" });

The documented parameters you can rely on are the ones in the tool docs: query, count, country, language, freshness, date_after, and date_before. Some providers add extra capabilities, but not every parameter works everywhere, so keep your portable workflows based on the shared set.

What web_fetch Actually Does

web_fetch is a different tool for a different job. It performs a plain HTTP GET and extracts readable content from the page. It does not execute JavaScript. The docs are explicit about that.

That means web_fetch is perfect when you already know the URL and want the article, docs page, or post content in markdown or text. It is not the right tool for logged-in apps, JS-heavy dashboards, or pages that render content only after client-side scripts run. For that, OpenClaw tells you to use the browser tool instead.

await web_fetch({
  url: "https://example.com/article",
  extractMode: "markdown",
  maxChars: 12000,
});

The supported parameters are small on purpose: url, extractMode, and maxChars. That is enough for most workflows because the heavy lifting happens in extraction, not in a giant parameter surface.

Search First, Fetch Second Is the Winning Pattern

The cleanest pattern in OpenClaw is: use web_search to discover relevant URLs, then use web_fetch to extract the actual content you want the model to read.

Why do I like this pattern so much? Because it keeps the agent honest. Search returns the candidate pages. Fetch reads the exact source you chose. That is much better than pretending a single black-box tool should discover, parse, summarize, and reason in one step.

1. Search for the topic or source you need.
2. Pick the most relevant result.
3. Fetch that URL for readable content.
4. Ask the model to analyze only the extracted text.

That workflow is especially good for product research, competitor checks, docs lookups, and current-events context inside a bounded task.

Configuring Web Search in OpenClaw

The docs give you two straightforward setup paths. You can run the interactive config flow:

openclaw configure --section web

Or you can place the relevant API key in the Gateway environment, for example BRAVE_API_KEY for Brave. For a gateway install, the docs specifically call out ~/.openclaw/.env as a place to store env vars.

A minimal config looks like this:

{
  tools: {
    web: {
      search: {
        enabled: true,
        provider: "brave",
        maxResults: 5,
        timeoutSeconds: 30,
        cacheTtlMinutes: 15,
      },
    },
  },
}

The defaults are sensible enough for most operators. Search is enabled by default, cache TTL is documented, and you can raise or lower the result count based on how much noise you want the agent to handle.

Brave is a practical default

The OpenClaw docs list Brave first in auto-detection and call out support for country and language filters. If you want straightforward structured results with snippets, Brave is a strong default. It is also the provider OpenClaw falls back to when no keys are found, at which point you will get a missing-key error that tells you to configure one.

That behavior is worth knowing because it makes failed setup easier to debug. If your agent says search needs configuration, you are not dealing with mystery behavior. You are hitting the documented no-key path.

Configuring web_fetch

web_fetch is even simpler. It is enabled by default, and the docs say the agent can call it immediately with no configuration required.

A representative config block looks like this:

{
  tools: {
    web: {
      fetch: {
        enabled: true,
        maxChars: 50000,
        maxCharsCap: 50000,
        maxResponseBytes: 2000000,
        timeoutSeconds: 30,
        cacheTtlMinutes: 15,
        maxRedirects: 3,
        readability: true,
      },
    },
  },
}

There are two details I really like here. First, maxChars is clamped by maxCharsCap, so callers cannot request unlimited output. Second, response size is capped before parsing, which matters when an agent hits an unexpectedly huge page.

How extraction works

The docs describe a four-step flow:

• Fetch the page over HTTP with a Chrome-like User-Agent and Accept-Language header.
• Run Readability to extract the main content.
• If extraction fails and Firecrawl is configured, retry through the Firecrawl API.
• Cache the result for 15 minutes by default.

That fallback design is good engineering. You get local extraction first, then a more capable external fallback only if needed. It also keeps the normal path fast and cheap.

What These Tools Do Not Do

This is where many agent stacks get sloppy, so let me be blunt. web_search is not browser automation. web_fetch does not execute JavaScript. If a site is JS-heavy, login-protected, or dependent on interactive state, OpenClaw's own docs tell you to switch to the browser tool.

That is not a limitation to work around. It is a clean boundary. The mistake is forcing the wrong tool into the wrong job and then blaming the platform.

If your agent needs to read a static docs page, use web_fetch. If it needs to log into a dashboard and click around, use the browser. If it needs to discover recent coverage on a topic, use web_search. Simpler tool boundaries usually produce better agents.

Safety and Guardrails Matter

OpenClaw puts real guardrails around web_fetch. The docs say private and internal hostnames are blocked, redirects are re-checked and limited, and oversized responses are truncated with a warning. Those are the kinds of boring details that matter in production.

Search also has bounded inputs. Result counts are limited, caching is built in, and provider selection is explicit. None of this is glamorous. All of it is what keeps your agent from turning web access into a messy, slow, expensive free-for-all. If you are building recurring jobs around this, pair it with OpenClaw cron jobs so the research loop runs on schedule instead of only when you remember.

Practical Workflows You Can Run Today

1. Docs lookup for coding agents

Use web_search to find the relevant docs page, then web_fetch to pull the canonical text before generating code or config changes. This is far better than asking the model to rely on stale training data.

2. Lightweight market research

Search for competitors, pricing pages, or launch posts. Then fetch the pages that actually matter. Keep the model grounded in extracted text instead of vague summaries.

3. Content monitoring

Run a recurring search for a brand term, product category, or feature name. Use the snippets to decide what deserves deeper fetching. This is a good fit for cron-driven monitoring.

4. Fact-checking before publishing

When your agent writes a post or summary, have it fetch the source URLs and compare claims against the extracted text. The cheaper your content operation is, the more you need this discipline.

One More Useful Distinction: Tool Access vs Browser Access

A lot of people hear “internet access” and immediately jump to “my agent needs a browser.” Sometimes it does. Often it does not. For a huge chunk of operator workflows, web_search plus web_fetch is cleaner than browser automation because it is lighter, faster, and easier to constrain.

Reserve the browser for sites that truly require JavaScript execution, login state, or UI actions. Use web tools for discovery and readable extraction. That split will make your agent stack cheaper and more reliable.

Final Advice: Give Your Agent the Web, but Keep the Contract Tight

The best OpenClaw setups do not give the model unlimited internet freedom. They give it structured access with predictable contracts. Search returns ranked candidates. Fetch returns readable text. Browser handles the messy stuff only when necessary.

That is the pattern I trust: small tools, clear boundaries, less hallucination, better results.

If your agent still feels boxed in, do not jump straight to more powerful models. First give it better access to reality.

Want the complete guide? Get ClawKit — $9.99