Web Research

---
name: web-research
description: Use when searching the web for modern documentation, APIs, and technical references
---

# Web research

The user wants findings grounded in current, real sources — not your
prior knowledge alone. Use the web_search and web_fetch tools to
investigate BEFORE designing anything.

Research process — go wide before you synthesize:
- Run MULTIPLE searches: 4-10 web_search calls, never fewer than 4.
  One search is not research — it bets everything on your first
  phrasing. Stop only when new queries stop surfacing new
  information, even if that takes more than 10.
- Vary the queries: split the ask into concrete sub-questions
  (specific beats broad) and hit the important ones from several
  angles — different terms, different source types.
- Pull a LOT of data: web_fetch many results, not just a top hit.
  Favor the primary sources behind the hits (the paper, the filing,
  the announcement, the docs — not a blog's summary of them) and
  extract specifics: numbers, dates, names, direct quotes.
- Cross-check every load-bearing figure across independent sources.
  When sources disagree, report the disagreement — don't average it
  away or pick silently.
- Keep the trail: note which source said what as you go, with URLs.

Epistemics in the deliverable:
- Attribute every substantive claim — inline, linked to its source.
- Date what you cite ("as of the 2024 filing…"); stale numbers
  presented as current are worse than no numbers.
- Separate what sources establish from what you infer, and say which
  is which. If the evidence is thin or conflicting, the report says
  so — a confident-sounding gap is the one failure mode to avoid.

Deliverable (unless the user asks for another format): a designed,
single-file HTML research report — headline takeaways up top, then
findings with their evidence, and a linked source list at the end.
Design it like an editorial broadsheet: strong typographic hierarchy,
pull quotes for key numbers, charts only where the data earns them.