Search Google and return the organic results - title, URL, snippet, domain, publication date - plus the surfaces around them: people_also_ask (related questions, often with a factual snippet), related_searches (reformulations), knowledge_graph (entity panel), and per-result sitelinks. READ THE SNIPPETS BEFORE FETCHING: for factual questions Google's snippet frequently states the answer outright (a pricing query returns the price), so you can often cite a source without spending a fetch. Use fetch when you need the full page, and deep_search when one page will not settle it. Returns up to 10 results. Costs 1 page.

Fetch the full, clean content of ONE web page as markdown. Use this to READ a result you got from web_search when the snippet isn't enough and you need the page's actual text - exact pricing, full docs, the complete article. Check the search snippet first: for many factual questions it already contains the answer, and a fetch costs a page. The url MUST be one a recent search in this session returned: fetch reads your grounded sources, it is not a general-purpose scraper for arbitrary URLs. Returns clean markdown in content (set clean=false for raw HTML), plus the page's title, its description, and the FINAL url after redirects - cite that one. Pass query (what you want from the page) to also get passages: the few most-relevant verbatim slices, so a tight context window can read those instead of the whole page. This call is synchronous - it returns the content or an honest failure, and you never poll. A page we could not really read is reported as a failure, NEVER as content, so you will not be handed a bot-wall or a consent screen to summarise. Costs 1 page per successful call; a failed fetch is free.

Search the web across several pages to answer a question in ONE call: it runs a search, fetches several of the top result pages, ranks passages across all of them, and returns the few verbatim slices most relevant to your question. Use this for a question that needs reading and comparing MULTIPLE pages ("which databases use X and how do they differ", "what do reviewers say about Y") instead of running web_search and then many fetch calls yourself - it does that multi-page reading for you and hands back only what fits your context window. Do NOT use it for a quick fact a single search snippet already answers (use web_search), or to read ONE page whose URL you already have (use fetch). Returns passages (verbatim, ranked, each with its source url) - it returns EVIDENCE, not a written answer: YOU read the passages and compose the answer, and YOU decide whether they actually answer your question (grounder does not judge that - it depends on what you are really asking). If the passages do not contain the answer, say so rather than guessing. If you would rather be handed prose than read the evidence yourself, set include_answer: true and the reply ALSO carries answer - a short answer written from those same passages. The passages still come back either way, so you can check the answer against its own evidence, and the field is omitted rather than guessed at when the passages do not support one. It costs no extra pages. The pack is capped to fit your context window (max_tokens, default 600) so it won't overflow a small local model. Slower than a single fetch (it reads several pages). Costs 1 page per page read (default up to 6).

INVESTIGATE an open question that has no ready-made answer sitting on any single page - the kind you would hand to a research analyst, not look up. The model DRIVES an iterative loop: it plans what to find, searches, reads the best PRIMARY sources, notices what is STILL missing, searches again, and reasons to a GROUNDED conclusion - or reports honestly that the web does not support one. Reach for it when the answer must be WORKED OUT, not retrieved: open/analytical ("is RAG becoming obsolete as context windows grow to millions of tokens?"), contested ("have LLM scaling laws hit diminishing returns, and why?"), or multi-part where the answer is spread across sources one search will not all surface ("how do Tavily, Exa and Firecrawl differ on pricing AND what each returns"). deep_search reads what ONE search surfaced; research works out what to search for at all and synthesizes an answer no single page states. Do NOT use it for a quick fact (web_search), a known page (fetch), or a question one search settles (deep_search) - it is slower and spends one of a small monthly allowance. It runs for a MINUTE OR MORE and is delivered by polling: if the reply is {"state": "researching"}, the work is still going - call again with the SAME query until you get the report (the MCP client does this for you automatically). Returns a cited evidence pack (passages with source urls) and, by default, a grounded answer written ONLY from those passages - never invented - that also names what the sources do not cover. Billed as ONE research run against your plan's monthly allowance, ONLY when it completes; polling is free.