Skip to main content
Glama
subimpact

subimpact-data-mcp

Official

google_search

Retrieve structured Google Search results as JSON, including AI Overview answers, organic results, People Also Ask, and knowledge graph data. Batch up to 1,000 queries per run for scalable SERP data collection.

Instructions

Google SERP + AI Overviews API

Google search as JSON: full AI Overview answers (lists, citations, sources) plus organic results, People Also Ask, knowledge graph, top stories and local results in one row per query. Batch up to 1,000 queries. From $1.80 per 1,000, platform costs included.

Pricing (pay per event, billed to your Apify account): Google SERP: $0.003.

Runs on Apify as subimpact/google-serp-ai-overviews.

Input Schema

NameRequiredDescriptionDefault
glNoTwo-letter country code for Google results, e.g. us, my, uk, sg.us
hlNoTwo-letter language code, e.g. en, ms, zh.en
udm56NoWhen true, appends &udm=56 to the search URL. Default FALSE after measurement (2026-09-07 A/B, 10 queries x 2 variants): udm=56 cut AIO coverage 8/10 to 4/10 and did not pin the classic surface (AI Mode share unchanged). Kept for control; leave off for Google's default routing.
mobileNoWhen true, fetches the SERP and the folsrch fragment with a mobile device header set (got-scraping header generator, devices: ['mobile']). Default FALSE. Measurement (2026-09-07 spike, 10 queries x 4 variants, gl=sg): mobile UA cut truncation 6/8 (75%) to 3/8 (37%), mean answer length 687 -> 852 chars, fetch success 15/20 -> 19/20. n=10, one market, one day — EnterRank's paired A/B (30 queries x 2, MY market) was inconclusive: zero of 29 queries were classic-with-an-overview in both arms (commercial prompt set routes to AI Mode). Do not flip the default until a classic-serving prompt set settles it.
queriesYesList of search queries to run. Max 1000 per run.
locationNoGeo target for results, e.g. "New York, NY" or "Kuala Lumpur". Empty = Google uses proxy IP geolocation. Encoded server-side via Google uule (same as SerpAPI).
_maxItemsNoHow many dataset items to return to the model (1-1000, default 50). Truncates the response only; it does not change what the Actor collects or charges for.
maxResultsNoHow many organic results to return per query (1-10, default 10).
concurrencyNoNumber of parallel queries (1-30, default 10). A/B measured: 20 queries at c5=34s, c10=35s, c20=65s — the SERP proxy pool is the bottleneck, so beyond ~10 workers latency balloons. 10 gives the same throughput as 5 with headroom for AI-Overview-heavy sets.
_maxChargeUsdNoPer-run spending cap in USD (default 0.5). Passed to Apify as the run option maxTotalChargeUsd, so the run stops when it reaches this charge.
excludeAiModeNoDefault TRUE. When Google serves the AI Mode surface instead of a classic AI Overview (after the optional retryAiModeForClassic re-fetch, if enabled), the row carries no ai_overview. search_metadata.ai_mode_detected and search_metadata.ai_mode_excluded are true. Organic results and People Also Ask are still delivered; the row is Success and charged, the same as a query Google shows no AI Overview for. Set to false to ship the AI Mode answer as before (flagged ai_mode_detected, Success, charged).
captureRawHtmlNoWhen true, saves the raw SERP HTML for every query to the key-value store (key: raw-<query>-<ts>.html). Used for building golden test corpora and debugging selector drift. Adds ~200-400KB per query to KV storage. Default false.
retryDeferredAIONoGoogle generates AI Overviews asynchronously — the first fetch sometimes returns only a placeholder shell. When true, the actor re-fetches (up to retryDeferredMaxFetches total) and keeps the richest response. Each retry costs one extra proxy request (~$0.0025) + compute on affected queries only. Set false to always use a single fetch per query.
resolveGotoTokensNoWhen true (default), AI Overview citations that still carry a raw /goto? token after the resolution chain are resolved by reading the Location header of google.com/goto?url=<token> (~90ms each, ~11.5% of citations). The original token is kept in goto_url as provenance; failures stay unresolved with unresolved_citations intact. Verified 93/93 by EnterRank + 6/6 by our probe. Set false to disable.
retryDeferredPollNoWhen true, re-fetches the SERP up to retryDeferredMaxFetches times when a deferred AI Overview shell is detected, keeping the richest response. Off by default: the folsrch recovery path resolves 90%+ of deferred AIOs, and the poll recovered 0/120 in the stress test while costing ~10s + extra proxy requests per shell query. Enable only if folsrch regresses.
retryThinOverviewNoWhen true, an AI Overview that came back partly rendered (ends in a dangling heading, or has under 600 characters of answer text) gets one fresh SERP fetch; the richer answer is kept, never a poorer one. Requires retryDeferredAIO and retryDeferredMaxFetches > 1. Costs one extra proxy request on affected rows only. Set false to ship thin answers as served.
retryPartialResultsNoGoogle intermittently serves a reduced page with other modules (People Also Ask, knowledge graph, top stories) but NO organic results. When true (default), the actor re-fetches to recover organics. Queries that stay organic-empty are marked status=Partial and NOT charged. Re-fetches are included in the price.
captureFlaggedFolsrchNoWhen true, and a query ends with truncation_detected true (AI Overview words missing: cut at an inline entity link, on an unclosed bracket, a trailing comma or a joining word), the answer's source HTML — the raw folsrch fragment when resolved_by is folsrch, else the shell — is saved to the default key-value store as folsrch-evidence-<query>-<ts>.html and search_metadata.folsrch_evidence points at the key. Diagnostic for studying exact cut points; best-effort, never fails a row. Adds one KV value per truncated row. Default false.
retryAiModeForClassicNoWhen true, an AI Mode serve triggers one re-fetch hoping for a classic AI Overview. Default FALSE after measurement (EnterRank, 2026-09-07, 101/101 answers across 4 runs): on a commercial query mix the re-fetch recovered ZERO classic serves — Google routes commercial queries to AI Mode today, so the re-fetch is a doubled SERP fetch with no recovery. Kept behind the input because routing moved once (2026-09-02: 2/2 re-fetches served classic) and can move back. When false (default), an AI Mode answer is not re-fetched: it is dropped (no ai_overview) when excludeAiMode is on (default), or shipped as-is (Success, ai_mode_detected: true, warning set, charged) when excludeAiMode is false.
retryPartialMaxFetchesNoUpper bound on total fetches per query when organic results are missing (retryPartialResults=true). 1 = no re-fetch, 2 = one re-fetch, 3 = two re-fetches. Range 1-3.
retryDeferredMaxFetchesNoUpper bound on total fetches per query when a deferred AI Overview shell is detected. 1 = single fetch (same as retryDeferredAIO=false). Higher = better recovery odds, more proxy usage on affected queries. Range 1-5.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does add real behavioral context that structured fields don't: pay-per-event billing to the Apify account, $0.003 per Google SERP, ~$1.80 per 1,000 queries, and the underlying Actor (subimpact/google-serp-ai-overviews). However, it says nothing about failure/partial-result behavior, AI Mode vs classic AI Overview routing, or default retry behavior — all of which materially change what comes back and are buried in parameter text.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose, then return contents, then scale, then pricing — a sensible ordering with little waste. The pricing and Actor-name lines are sales/origin metadata rather than invocation guidance, which slightly dilutes the signal, but the whole thing is short enough that no sentence is a real burden.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 21 parameters, no annotations, and no output schema, the description should do more than list result modules. 'One row per query' hints at the response shape but doesn't say what a row's fields look like or what happens on AI-Mode serves, deferred AI Overviews, or Partial rows — behaviors an agent must understand before tuning the many retry/exclusion flags. Adequate as a front door, incomplete for this tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across 21 parameters, so the schema already documents each field thoroughly. The description contributes only the batching ceiling ('Batch up to 1,000 queries'), which merely restates the queries array constraint. Baseline 3 is appropriate when the schema does all the semantic work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb+resource — Google SERP scraping with AI Overviews — and enumerates exactly what is returned (AI Overview answers with lists/citations/sources, organic results, People Also Ask, knowledge graph, top stories, local results) in one row per query. It is clear and specific, but it never distinguishes itself from the sibling google_ai_mode, which an agent could easily confuse with this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use / when-not-to-use guidance and no named alternative. The reader must infer from the feature list that this is for bulk SERP retrieval, and the presence of google_ai_mode and google_trends as siblings makes the lack of routing guidance a real gap. Batch size (up to 1,000 queries) and price are stated, but those are limits, not selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.