Whether the dedicated profile has a live Google session, and which account it is.

Worth calling once before relying on personalization: signed out still works, it just returns the neutral (unpersonalized) view. The account is read off the page rather than assumed, because "whoever was signed in" is not a safe default on a box with more than one Google account.

Search Google. Ads stripped; results are {rank, title, url, host, snippet, date}.

Use the structured arguments rather than typing operators into query -- they assemble the correct syntax for you:

site='arxiv.org' restrict to one domain filetype='pdf' only PDFs exact='model context protocol' quoted phrase, must appear verbatim exclude=['tutorial'] drop results containing a term after='2026-01-01' published after a date (before= for the other bound) freshness='week' hour | day | week | month | year verbatim=True no synonyms or stemming; the words as typed strict_dates=True apply before/after as Tools > Custom range instead of as query operators (index date rather than document date) country='de', lang='de' region and language bias personalized=False the neutral view, no account history applied

vertical selects which Google tab to read:

web the default SERP, including rich blocks web_only the "Web" tab -- plain links, no rich blocks. Cleanest for research; measured 17 external anchors against 56 on the default SERP. news news, with dates videos video results short_videos the shorts feed books Google Books (results are google-hosted by nature) images the image grid; single page, title comes from alt text

date is populated where Google shows one ("2 days ago", "28 Jul 2026") and is null otherwise. total_matches is Google's own estimate for the whole query, not the number returned.

with_content=True also READS the top content_top_n results and attaches each as markdown on result.content, saving a fetch round trip per link. It goes through the same logged-in browser, so it reads JS-rendered pages and soft paywalls that a plain HTTP fetch cannot. Costs a real page load each -- budget a few seconds per result, and raise content_chars (default 2000) only when you actually need the whole article. A page that could not be read sets content: null and content_error.

pages is 10 results each, max 5, and each page is a separate round trip -- ask for depth only when you actually need it. Ignored for images.

On failure the result carries a kind field: auth_expired (sign in), schema_drift (the extractor is stale, do not retry), rate_limited (back off). An empty result set is NOT an error -- it returns count=0 with no kind, and means Google matched nothing.

Read web pages as markdown, through the warmed logged-in browser.

Use this instead of a plain HTTP fetch when the page needs a real browser: JS-rendered apps, soft paywalls, cookie-walled articles, anything behind the Google login. That capability is the whole point -- for a static public page an ordinary fetch is cheaper.

Boilerplate (nav, footers, cookie banners, related-story rails) is stripped and only the article body comes back, so the payload is a fraction of the raw HTML. Output is markdown, which keeps headings, lists and code fences intact.

Capped at 5 URLs per call and read sequentially with per-host throttling -- this is a real browser making real requests. max_chars truncates each page on a paragraph boundary and sets truncated with the full length in chars_total.

A page that cannot be read comes back with ok: false and a reason rather than sinking the call.

Google's AI Mode answer for a query, with the sources it cites.

The answer is unreliable. Treat it as a lead, never as a fact. It is hit or miss, it is confidently wrong at the same tone it is right, and it is not authoritative even about Google's own products -- which is the trap, because those are exactly the queries where it reads most credible. Nothing from here should reach a user, a document or a decision without being confirmed against a real source.

The citations are the valuable part; the prose is a map to them. Normal use is: read this for orientation on an unfamiliar topic, then google_search for the primary sources and believe those instead. For anything load-bearing, skip this tool.

Absence is normal. AI Mode is not offered for every query, region or account. When it is not there you get available: False and a reason, NOT an error and NOT schema_drift -- so do not retry the same query hoping for a different shape.

Slower than a search: the answer streams, and this polls until it stops growing (typically ~4s, capped at 20s).

Run several related queries in one call. Prefer this when researching a topic.

Google makes you search, read ten results, then search again -- and every separate tool call otherwise pays the browser launch and warm-up again. This amortises that across the whole set.

Runs sequentially on purpose: concurrent requests are exactly what Google's anti-bot watches for, so the win here is the shared warm browser, not parallelism. Budget roughly 5-7 seconds per query after the first.

One failing query does not sink the call -- failures land in errors keyed by query, and the rest still return. A rate_limited stops the run early rather than hammering.