Fetch a URL and return clean, extracted text content (boilerplate, ads, and nav removed). Use to read articles, documentation pages, or API responses in full. For broad queries, use web_search first, then fetch specific URLs from its results. After fetching, look for technical terms, names, or references you can use as keywords for a better follow-up search.

⚠️ FAILURE IS NORMAL — DO NOT GIVE UP AFTER 1-2 FAILED FETCHES:

• If a fetch returns empty body, 403, or obvious JS-template garbage, try the NEXT URL from the search results immediately. Each retry costs only ~0.5s.

• Common failure causes: JS-rendered SPA shells (stock pages, forums), Chinese paywalls/captchas (wenku.baidu.com, zhihu.com), government site timeouts.

• Rule of thumb: try at least 3 URLs from 3 different domains before concluding the content is unreachable. Skipping this wastes the search you already paid for.

• When retrying, pick a URL from a DIFFERENT domain — same-domain failures often share the same root cause (e.g., all pages behind the same Cloudflare/WAF).

RETRY SILENTLY: When a fetch fails, retry with the next URL immediately as another tool call. Do NOT narrate each failure to the user ('this one failed, trying another…'). Only mention failures in your final reply if ALL attempts were exhausted.

Search the web via multiple engines (Baidu, Sogou, Bing CN, Bing Intl). Returns ranked titles, URLs, and snippets (no full page content — use web_fetch to get the full text of any result). Results re-ranked by embedding similarity — the top results are the most relevant.

Iterative search is normal: search → read → refine → search → read → synthesize. Search returns only titles + snippets. Read snippets to identify promising results, then call web_fetch to get full page content for the URLs that look most useful.

BEFORE FETCHING, READ THE SNIPPETS FIRST:

• Search results come with title + URL + snippet only (no full content). Read snippets to decide which URLs are worth fetching.

• Fetch only the 1-3 most promising URLs — do not blindly fetch everything. Each unnecessary web_fetch wastes 1-3s per call.

⛔ WHEN RESULTS LOOK WRONG, DO NOT GIVE UP — ITERATE IMMEDIATELY: If search results are all irrelevant (wrong topic, wrong domain, generic encyclopedia entries, piracy sites, brand pages, file format tools, or dictionary entries), DO NOT conclude the information is unavailable. The fix is almost always a query reformulation. The most common root cause is Bing's tokenizer splitting your query words into fragments that collide with unrelated content. Replace fragile/generic terms with INSEPARABLE identifiers — proper nouns, compound terms, subdomain names, or acronyms that the tokenizer CANNOT split. Then immediately re-search. Do not narrate the failure — just try a different formulation. The PRINCIPLE (not the specific domain) matters:

• A law query: 'GDPR enforcement tracker 2026' not 'GDPR fine'

• A car query: '全固态电池量产线' not 'solid state battery'

• A finance query: 'USDJPY exchange rate' not 'yen dollar'

• A programming query: 'rustc 1.87 changelog' not 'Rust release notes'

• FOR CHINESE: no spaces around Chinese chars! '2026年新能源汽车补贴' ✓, '新能源汽车补贴 2026' ✗

SEARCH STRATEGY (patterns drawn from real-world use):

1. DATE TERMS HIJACK QUERIES — Putting year numbers or month names ("2026年", "June") directly in query text often backfires: the engine weights them as the primary topic and you get calendar summaries or current-events roundups instead of your actual topic. PREFER the 'freshness' parameter to control recency — it filters by publication date without polluting the query text.

2. SHORT COMMON WORDS COLLIDE — In Chinese, single characters that are also standalone dictionary headwords get tokenized independently and matched to dictionary/encyclopedia entries, regardless of surrounding context. In English, short common words that also name major products/services (credit card brands, consumer goods) cause the same problem. RECOGNISE THE PATTERN: if any word in your query could appear as a dictionary headword or a product name on its own, it WILL collide. Embed such terms inside longer inseparable compounds.

3. LONG PROPER NOUNS ARE ANTI-NOISE ANCHORS — Full institutional names, drug trade names, legal case codes, product model numbers resist tokenizer fragmentation. They act as unbreakable signals that pull results toward the right topic. When a shorter query goes off-target, try a version built around a specific long-form name.

4. LANGUAGE-SWITCH ESCAPES TOKENIZER TRAPS — When a Chinese query keeps hitting noise despite retries, switch the query to English. English-language media covers many China-specific topics, and the English tokenizer does not fragment CJK characters into dictionary entries.

5. REPLACE THE ANCHOR — Adding another word to a noisy query rarely fixes it (the original offending token still dominates the ranking). Instead, restructure the query around a DIFFERENT anchor term entirely — a proper noun, a model number, or a multi-word technical phrase that the tokenizer cannot split.

6. THE VOCABULARY BRIDGE — Chinese search engines match on LEXICOGRAPHIC (word-level), NOT semantic. The words you use MUST match how the target documents actually phrase things. This creates a critical gap:

• User language (descriptive): 极端天气, 气候灾害, 高温热浪

• Source language (operational): 暴雨橙警, 三级应急响应, 解除预警 These are two entirely different vocabulary systems and the engine CANNOT automatically map between them. When abstract category terms return only encyclopedia definitions and year-old retrospectives, switch to the OPERATIONAL terms that the institutions/sources themselves use — alert levels, government response codes, proper institutional names, numeric thresholds ("四十度"), or named entities ("台风蔷薇").

• Abstract: '2026年极端天气气候灾害' → only dictionaries & retrospectives

• Operational: '暴雨橙警 应急响应 中央气象台' → nmc.cn real-time alerts This is not a data-coverage problem. The documents exist in the index. They just use a different vocabulary than you searched for.

⚡ NUMERIC DATA CROSS-VERIFICATION:

• When a critical number appears in one result, confirm it against at least one other source before accepting it as fact. Different aggregators can lag; conflicting values demand a third source.

⛔ DO NOT STOP EARLY — PERSISTENCE IS REQUIRED:

• When a search returns 10 irrelevant results, that does NOT mean the information doesn't exist. It means the current query formulation failed to reach it. Real-world testing shows: the same engine (baidu/bing_cn) that returned 100% calendar-dictionary noise for '2026年极端天气' returned nmc.cn real-time severe weather alerts (rerank 0.908) when reformulated as '暴雨洪涝 应急响应 中央气象台 预警'.

• Top-10 failure is a QUERY PROBLEM, not a content-availability problem. The valid pages are likely at positions 11-30, pushed out of view by noise that matched your abstract terms. Do not conclude 'information unavailable' from a failed top 10.

• EXHAUST AT LEAST 3-4 DISTINCT STRATEGIES before any 'not found' verdict:

  1. Different vocabulary (descriptive → operational)

  2. Different language (CN ↔ EN)

  3. Different anchors (category term → proper name/number)

  4. Site-restricted search (site:target-source.tld)

• Never stop after 1-2 rounds just because the first attempts returned noise. The difference between 'completely unsolvable' and 'fully answered in 1 round' is often a single query reformulation — changing '极端天气' to '暴雨橙警'.

CONDUCT ALL ITERATIONS SILENTLY: When you need multiple rounds of searching and fetching to gather information, run all iterations as tool calls without narrating each step in your reply. Present only the final synthesized answer to the user. Do NOT say things like 'let me search again' or 'I tried searching for X but got Y, let me try Z instead' — just do it and deliver the result.