Observation & data
Ranked web results, optionally with the pages read
Blended ranked results across web, discussions, news and FAQ clusters plus Hacker News, deduped by URL and tagged with their source — and, on request, the cleaned readable text of the top few.
search
What it is
The job: Find pages, and optionally have them read for you, in one call.
Results blend several source clusters — web, discussions, news, FAQ and Hacker News — deduped by URL, with a `source` field on each result so you can tell where it came from. That matters more than it sounds: an agent researching a product wants the discussion thread and the news item weighted differently, and it cannot do that if everything arrives flat.
Set fetchContent to also navigate the top N results and return their cleaned readable text. This is a real browser fetch, not a text scrape of the SERP snippet, and it runs no model — the cleaning is deterministic. That keeps the call flat-billed and the output predictable.
It is synchronous. For the version that scrapes harder and platform-aware, and returns a job id instead of blocking, use deep_search.
The call
Call it exactly like this.
Copied from the tool's registration and the route handler — not paraphrased.
// MCP tool call — server "twin-browser"
{
"tool": "search",
"arguments": {
"query": "playwright vs puppeteer stealth 2026",
"count": 10,
"fetchContent": true,
"topN": 3
}
}curl -X POST https://twin-browser.com/api/v1/search \
-H "Authorization: Bearer $TWIN_API_KEY" \
-H "content-type: application/json" \
-d '{"query":"playwright vs puppeteer stealth 2026","count":10,"fetchContent":true,"topN":3}'| Parameter | Type | What it does |
|---|---|---|
| query* | string | The search query. |
| count | number | Number of ranked results, 1–20. Default 10. |
| fetchContent | boolean | Also fetch and clean the content of the top results. Default false. |
| topN | number | How many top results to fetch content for, 1–10. Default 3. Needs fetchContent. |
| proxy | string | Your own egress proxy URL for the content fetches. |
| waitMs | number | Settle wait in milliseconds after load, before reading content. |
Returns
{
"query": "…",
"results": [
{ "title": "…", "url": "https://…", "snippet": "…", "source": "web",
"content": "…" } // present for the top N when fetchContent is set
],
"fetched": 3,
"llmCostMicro": 0,
"credits_charged": 6
}What it costs
3 credits + 1 per page fetched
Flat and predictable: 3 credits for the ranked results, plus 1 credit for each page actually fetched when fetchContent is set. No model runs, so nothing is metered on top. You are billed for pages fetched, not pages requested.
See the full rate cardWhich one
When a different tool is the right call.
The honest answer is often the neighbouring tool. These are the trades.
deep_searchdeep_search scrapes the top results platform-aware (Reddit, X and others that a plain fetch does not read well) and runs as a job. It costs more per page and gets content a shallow fetch cannot. Use search when the top three plain pages are enough.
deep_searchmap_siteDifferent question. search finds pages across the web; map_site enumerates the URLs of one site you already know about.
map_siteQuestions
search, answered.
- Is fetchContent an LLM summary?
- No. It is a real browser load of the result page followed by deterministic content cleaning. No model reads it and nothing is summarized, which is why the billing is flat per page and the output is the page’s own text rather than an interpretation of it.
Keep going