Beginner’s Guide to OpenClaw Tools: Browser, Exec & Search

Look, I'm going to save you about six hours of frustration.

If you've been poking around OpenClaw trying to figure out what the Browser, Exec, and Search tools actually do — and more importantly, how to wire them together without everything falling apart — this post is for you. I spent weeks banging my head against this stuff before it clicked, and I'm going to compress that entire learning curve into something you can read over one cup of coffee.

Here's the truth: most people who quit OpenClaw quit in the first 48 hours. Not because the platform is bad, but because they try to do too much at once, get confused by the tool system, and walk away thinking it's broken. It's not broken. You just need someone to explain the mental model, and then everything snaps into place.

Let's do that.

What OpenClaw Actually Is (In Plain English)

OpenClaw is a platform for building AI agents that can actually do things — not just generate text, but browse the web, execute code, search for information, and chain those actions together into workflows that run with minimal hand-holding.

The core concept is simple: you give an agent a set of tools (capabilities it can use), a task (what you want done), and skills (pre-configured patterns for how to approach common problems). The agent figures out which tools to use, in what order, and handles the back-and-forth until the job is done.

The three tools you'll use most often are Browser, Exec, and Search. They sound self-explanatory, but each one has quirks that will trip you up if you don't understand them. So let's break them down one at a time.

Tool #1: Search

I'm starting with Search because it's the simplest and the one you should experiment with first.

What it does: Search lets your agent query the web and pull back structured results — titles, URLs, snippets, and sometimes full page content depending on your configuration.

Why it matters: Without Search, your agent is limited to whatever's in its training data. With Search, it can look things up in real time. This is what turns a chatbot into a research assistant.

Here's a basic skill configuration that uses Search:

name: research_assistant
tools:
  - search
instructions: |
  When the user asks a question, search for the most recent 
  and authoritative information before answering. Always cite 
  your sources with URLs. If the search results are ambiguous, 
  run a second search with a more specific query.
max_search_results: 5
search_depth: standard

The mistake everyone makes: They give the agent a vague instruction and expect Search to magically return perfect results. It won't. The quality of your agent's output is directly proportional to how well you coach it on query formulation.

Compare these two instruction blocks:

# Bad - vague, no guidance on HOW to search
instructions: |
  Answer the user's questions using search.

# Good - specific, teaches the agent to search well
instructions: |
  When answering questions, formulate 2-3 specific search queries 
  rather than one broad query. Prefer queries that include specific 
  names, dates, or technical terms. If initial results seem outdated 
  (more than 6 months old for fast-moving topics), reformulate with 
  the current year included in the query.

That second version will dramatically improve your results. The agent isn't dumb — it just needs the same kind of guidance you'd give a new intern doing research for the first time.

Pro tip: Set max_search_results to 5 for most use cases. Going higher sounds better but actually makes things worse — the agent gets overwhelmed with context and starts cherry-picking from random results instead of synthesizing the best ones. If you're doing deep research and need more breadth, bump it to 10 and add an explicit instruction to summarize and rank results before synthesizing.

Tool #2: Browser

Browser is where things get interesting — and where most beginners get stuck.

What it does: Browser gives your agent the ability to actually visit web pages, read their content, interact with elements, and extract structured data. Think of it as giving your agent a real web browser it can control.

How it's different from Search: Search gives you snippets and URLs. Browser actually goes to the page and reads the whole thing. You typically use Search to find what you're looking for, then Browser to dive deep into specific pages.

Here's an example that chains them together:

name: competitive_intel
tools:
  - search
  - browser
instructions: |
  The user will give you a company name. Your job:
  1. Search for the company's official website and recent news
  2. Browse their homepage and extract: tagline, main product 
     categories, and any visible pricing information
  3. Browse their "About" or "Company" page for founding year, 
     team size, and headquarters location
  4. Search for recent news articles about the company (last 90 days)
  5. Browse the top 3 news results and summarize key developments
  6. Return a structured briefing with all findings
output_format: |
  ## Company Briefing: {company_name}
  ### Overview
  ### Products & Pricing
  ### Recent Developments
  ### Sources

The mistake everyone makes with Browser: They try to use it for everything. Browser is slow compared to Search. Every page visit takes time and uses tokens to process the page content. If you just need a quick factual answer, Search is almost always better. Use Browser when you need:

• Full page content (not just snippets)
• Data from specific pages you already know the URL of
• Information that's buried deep in a page (pricing tables, technical specs)
• Content from pages that don't show up well in search snippets

Handling Browser failures: Pages fail to load. Sites block bots. JavaScript-heavy pages render blank. Your agent needs to know what to do when Browser hits a wall. Add explicit fallback instructions:

instructions: |
  ...
  If a page fails to load or returns minimal content, do NOT 
  retry the same URL more than once. Instead:
  1. Try a cached version by searching for "cache:{url}"
  2. Search for the specific information you needed from that 
     page using a targeted query
  3. If neither works, note the gap in your output and move on
  
  Never loop on a failing page. Maximum 2 attempts per URL.

That last line is crucial. Without it, you'll get agents that burn through your usage trying to load the same broken page fifteen times in a row. I learned this the hard way on a monitoring agent that racked up charges at 3 AM because it was stuck in a retry loop on a site that was down for maintenance.

Tool #3: Exec

Exec is the power tool. It's also the one that scares people, and honestly, a healthy respect for it is warranted.

What it does: Exec lets your agent write and run code. Python, shell commands, data processing scripts — whatever you need to transform, calculate, or automate that goes beyond what an LLM can do in its head.

When you need it: Anytime your agent needs to do math on real data, transform file formats, process CSVs, generate charts, or perform any operation where precision matters more than vibes.

name: data_analyst
tools:
  - search
  - exec
instructions: |
  The user will provide datasets or ask analytical questions.
  Use exec to write Python code for:
  - Data cleaning and transformation
  - Statistical calculations
  - Generating summary tables
  
  Always use pandas for data manipulation. Show your work by 
  printing intermediate results. If a calculation seems wrong 
  or produces unexpected output, re-examine the data and try 
  a different approach before reporting results.
  
  IMPORTANT: Never use exec to install packages, access the 
  file system outside the working directory, or make network 
  requests. Use the search tool for web access instead.
allowed_packages:
  - pandas
  - numpy
  - statistics

The mistake everyone makes with Exec: Two things, actually.

First, they don't constrain it enough. An agent with unrestricted Exec access can and will do weird things. Set explicit boundaries on what packages are available, what directories it can access, and what operations are off-limits. OpenClaw's configuration supports these constraints — use them.

Second, they don't tell the agent to validate its own output. LLMs are confident even when their code is wrong. Add instructions like:

instructions: |
  ...
  After running any calculation:
  1. Print the result
  2. Sanity check it — does the number make sense given the input?
  3. If working with percentages, verify they sum correctly
  4. If merging datasets, verify row counts before and after

This one addition cut my error rate roughly in half. The agent catches its own mistakes when you explicitly tell it to look for them.

Putting It All Together: A Real Workflow

Here's a skill configuration that uses all three tools together. This is a "market research assistant" that takes a product idea and returns a competitive analysis:

name: market_research_agent
tools:
  - search
  - browser
  - exec
instructions: |
  The user will describe a product or business idea. Your job is 
  to produce a competitive landscape analysis. Follow this process:
  
  PHASE 1 - Discovery (use Search)
  - Search for existing products/services in this space
  - Search for market size estimates and growth trends
  - Search for the top 5-10 competitors
  
  PHASE 2 - Deep Dive (use Browser)
  - Visit each competitor's website
  - Extract: pricing model, key features, target audience, 
    any visible traction metrics (customers, revenue, etc.)
  - Visit 2-3 review sites (G2, Capterra, TrustPilot) for 
    each major competitor
  
  PHASE 3 - Analysis (use Exec)
  - Create a comparison table of all competitors with columns 
    for: name, pricing, key differentiator, strengths, weaknesses
  - Calculate the average price point in the market
  - If market size data was found, compute the estimated 
    revenue per competitor based on market share
  
  PHASE 4 - Synthesis
  - Write a briefing that includes:
    - Market overview (size, growth, trends)
    - Competitor comparison table
    - Identified gaps in the market
    - Recommended positioning for the user's product
    - Top 3 risks
    
  Be thorough but efficient. Don't browse pages you don't need.
  Don't run code for things you can calculate mentally.
  Cite every factual claim with a source URL.

max_search_results: 8
search_depth: deep
max_browser_pages: 15
exec_timeout: 30

This is a non-trivial agent. It does real work across multiple phases, uses each tool where it's strongest, and produces genuinely useful output. I've used variations of this to evaluate markets before committing time and money to new projects, and it consistently surfaces competitors and pricing data that would've taken me days to compile manually.

The Biggest Lesson: Tool Descriptions Are Everything

If you only take one thing from this post, make it this: the quality of your agent's tool use is 90% determined by the quality of your instructions and tool descriptions.

The same agent with the same tools will produce wildly different results depending on how you describe what those tools do and when to use them. This isn't a bug — it's the fundamental nature of how these systems work.

Spend your time on:

1. Clear, specific instructions — not "research this topic" but "search for X, then browse the top 3 results, then synthesize findings into a structured format"
2. Explicit failure handling — what should the agent do when a search returns nothing useful? When a page won't load? When code throws an error?
3. Constraints and guardrails — what should the agent not do? How many retries are allowed? What's the maximum number of pages to browse?
4. Output format specifications — don't leave the output format to chance. Define exactly what you want back.

Getting Started Without the Setup Headache

Now here's the practical reality: configuring all of this from scratch takes time. Writing good skill definitions, debugging tool interactions, figuring out the right constraints — it's a learning process, and the first few iterations are usually pretty rough.

If you want to skip the initial trial-and-error phase, Felix's OpenClaw Starter Pack on Claw Mart is genuinely worth the $29. It includes pre-configured skills that already have the Search, Browser, and Exec tools wired up with solid default instructions, proper error handling, and sensible constraints. The research assistant skill alone would've saved me a weekend of tweaking.

I'm not saying you can't build all of this yourself — everything I've described above is totally doable by hand. But the starter pack gives you working examples to learn from, which is significantly faster than starting from a blank YAML file and guessing. Think of it less as a shortcut and more as a set of reference implementations that you'll customize as you learn what works for your specific use cases.

Common Mistakes (And How to Avoid Them)

Let me rapid-fire the mistakes I see beginners make most often:

Giving the agent too many tools at once. Start with one tool. Get comfortable. Add the second. Then the third. An agent with 10 tools and vague instructions will almost always pick the wrong one.

Not setting timeouts. Especially on Browser and Exec. An agent that runs forever costs you money and produces nothing. Set explicit timeouts and tell the agent what to do when it hits them.

Writing instructions like you're talking to a human. Humans fill in gaps with common sense. Agents don't. If you want the agent to search before answering, say "always search before answering." If you want it to cite sources, say "include the URL for every factual claim." Be annoyingly explicit.

Ignoring the output. Run your agent, read the full trace of what it did, and look for inefficiencies. Did it search for the same thing three times? Did it browse a page it didn't need? Did it run code that was unnecessary? Each of those is a clue about how to improve your instructions.

Treating agents as magic. They're not. They're loops that call tools based on pattern matching against your instructions. The better your instructions, the better the pattern matching. There's no shortcut for this — you have to iterate.

What to Build Next

Once you're comfortable with Browser, Exec, and Search, here's where I'd go:

1. Build a personal research agent that takes a topic and produces a structured briefing. This is the simplest useful thing you can build and it'll teach you how all three tools interact.

2. Build a monitoring agent that checks specific pages daily and alerts you to changes. This teaches you about scheduling and state management.

3. Build a data pipeline agent that takes messy input (CSV, API responses, scraped data) and produces clean, structured output. This is where Exec really shines.

Each of these builds on the last, and by the time you've done all three, you'll understand OpenClaw's tool system deeply enough to build basically anything.

The tools aren't complicated. The agent loop isn't complicated. What's complicated is writing instructions that make an AI reliably do what you want — and the only way to get good at that is to build things, read the traces, and iterate.

Stop reading. Go build something. You'll learn more in one hour of hands-on experimentation than in ten hours of reading documentation.