Skip to main content
Glama
subimpact

subimpact-data-mcp

Official
by subimpact
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

google_maps_places

Scrape Google Maps places by keyword, location, or place ID to collect address, phone, website, rating, reviews, hours, and images for lead generation and local research.

Instructions

Google Maps Scraper

Extract Google Maps places: title, address, coords, phone, website, rating, reviews count, opening hours, popular times, images, price level, menu, place ID. Search by keyword + location or place IDs. Plain-HTTP internal API, no browser, fast and cheap. $1.00 per 1,000 places.

Pricing (pay per event, billed to your Apify account): Place scraped: $0.001; Review scraped: $0.0005; Actor start: $0.00005; platform usage billed to your account.

Runs on Apify as subimpact/google-maps-scraper-plainhttp.

Input Schema

NameRequiredDescriptionDefault
latNoOptional. Center latitude of the search viewport. Leave empty (with longitude) to let Google resolve the location from each search string.
lngNoOptional. Center longitude of the search viewport. Only used together with latitude; empty = resolve from the search string.
zoomNoMap zoom for the search viewport. Higher = smaller area, fewer but denser results.
languageNoResults language.en
placeIdsNoDirect place detail scrape by ChIJ place ID.
_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.
startUrlsNoDirect place detail scrape by maps.google.com place URL.
maxReviewsNoNumber of reviews to extract per place. 0 = none. Each review = review-scraped charge.
_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.
proxyConfigurationNoOptional. Residential proxies recommended for large runs from datacenter IPs.
searchStringsArrayNoWhat to search on Google Maps. Each term = one search. A term can be a business name plus its full address (compass-style exact lookup) - Google resolves the location from the string, no coordinates needed.
scrapePlaceDetailPageNoOpen each place's detail payload (phone, hours, popular times, images, price). Off = search-level records only.
maxCrawledPlacesPerSearchNoMax places per search term (compass semantics). Each search string can return up to this many places; a run with N terms returns up to N x this. Detail records are charged per place.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the whole burden and does substantial work: it discloses the plain-HTTP/no-browser approach, per-event pricing ($0.001/place, $0.0005/review), the spending-cap mechanism, and that _maxItems truncates only the response, not collection or charges. It omits auth requirements, expected run duration, and failure/rate-limit behavior.

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 extraction capability and fields, followed by pricing and hosting details. The pricing paragraph is somewhat verbose and partly duplicates schema-level cost notes, but every block is separated and scannable; nothing is buried mid-sentence.

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?

For a 13-parameter, no-output-schema tool the description compensates well by enumerating returned fields and disclosing cost behavior. Remaining gaps are the response shape (dataset item structure), run latency, and how the three input modes (search strings, placeIds, startUrls) relate when combined.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3; the description adds value by tying cost semantics to parameters ('$1.00 per 1,000 places', per-review charges), which clarifies the financial impact of maxReviews and maxCrawledPlacesPerSearch beyond their schema text. It does not explain the interaction between lat/lng and searchStringsArray, which the schema does cover.

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+resource (extract Google Maps places) and enumerates the returned fields (title, address, phone, rating, hours, place ID, etc.). It also distinguishes the two input modes: keyword+location search versus direct place-ID lookup, so an agent can tell it apart from sibling tools like google_search or website_contacts.

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

Usage Guidelines3/5

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

The description implies usage via 'Search by keyword + location or place IDs' and the schema notes hint at exact-lookup vs discovery, but it never explicitly says when to prefer this over siblings such as google_search, nor when not to use it. Guidance is implied rather than stated.

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