Skip to main content
Glama
paulet4a-commits

webdatatools-social-mcp

by paulet4a-commits
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

google_search_scraper

Scrape Google search results for any query and return organic titles, URLs, snippets, and positions. Each SERP page returns one row and is billed per page.

Instructions

Google Search Results Scraper returns organic results (title, real URL, snippet, position) for any query through the Apify GOOGLE_SERP proxy — one row per SERP page, priced per page not per result. Billed to your own Apify account: ~$0.005 per result (Apify free-plan price, lower on paid plans).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deviceNoDevice — Choose desktop or mobile to control which User-Agent is sent — Google sometimes shows slightly different snippets/layout per device. Options: desktop = Desktop; mobile = Mobile.desktop
queriesYesSearch queries — Enter the Google search queries to scrape, e.g. apify web scraping. One dataset row is returned per query per result page. Example: ["apify web scraping"].
safeSearchNoSafeSearch — Turn this on to request Google's SafeSearch filtering (adds safe=active to the request).
countryCodeNoCountry code (gl) — Enter the 2-letter country code Google should localise results for, e.g. us, gb, de. Sent as the gl parameter.us
languageCodeNoLanguage code (hl) — Enter the 2-letter interface language code, e.g. en, es, fr. Sent as the hl parameter and affects snippet language.en
resultsPerPageNoResults per page — Enter how many results Google should return per page, e.g. 10. Higher values (up to 100) fit more organic results on one billed page but Google may still cap what it actually returns.
maxPagesPerQueryNoMax pages per query — Enter how many result pages to fetch per query, e.g. 1. Each extra page is a separate billed SERP page (start=N*resultsPerPage).
includePeopleAlsoAskNoInclude People Also Ask — Keep this on to parse the People Also Ask question box. Note: Google only loads each answer's text/link after a click, so answerSnippet/url are often null — only the question text is reliably available.
includeRelatedSearchesNoInclude related searches — Keep this on to parse the related-searches suggestions shown near the bottom of the page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

No annotations are provided, so the description carries full behavioral burden, and it delivers uncommon value: it discloses output granularity (one row per SERP page), a per-page rather than per-result pricing model, and self-billed Apify cost (~$0.005/result). It stops short of covering auth/token setup, rate limits, or error behavior, so it is strong but not complete.

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?

Two sentences front-load the deliverable and then the cost model, with no filler. Effective and appropriately sized, though it could be marginally tighter in the pricing clause.

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

Completeness4/5

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

With no output schema, the description correctly describes return fields and row granularity plus the cost model. For a 9-parameter scraper it is nearly complete, missing only error/retry and async behavior context.

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% and the parameter descriptions are already detailed (gl/hl mappings, billing implications of resultsPerPage and maxPagesPerQuery), so the description adds little parameter-specific meaning. Baseline 3 is correct when the schema does the heavy lifting.

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

Purpose5/5

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

States a specific verb and resource — returns organic Google results (title, real URL, snippet, position) for any query — so the agent knows exactly what it produces. It is unmistakably distinct from the sibling scrapers (YouTube, podcast, Bluesky, Telegram, Substack), which are all different platforms.

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?

The description says what the tool does but never states when to use it versus alternatives or any preconditions. With siblings covering unrelated platforms selection is somewhat obvious, but there is no explicit when-to-use or when-not guidance, leaving usage to inference.

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

Deploy Server

Other Tools