Outscraper MCP

Official

Overview Schema Source Related Servers Discussions Admin

Google Maps Search

google_maps_search

Search Google Maps places using natural-language queries to discover businesses, restaurants, and services. Supports multiple queries, async execution, and enrichments for deeper place data.

Instructions

Search Google Maps places through Outscraper.

Best for:

ad hoc place discovery from one or more Google Maps queries
cases where the user thinks in Google Maps terms rather than /businesses filters
retrieving place results directly from the Google Maps search pipeline

Prefer this tool when:

the user gives Google Maps-style queries such as "restaurants brooklyn usa"
you want place discovery without building structured business filters first
you want async submissions for larger query batches or enriched Google Maps searches

Use businesses_search instead when:

you want normalized businesses filters or cursor pagination
you want to combine strict filters with natural-language business search

Use execution_mode="auto" when:

there are multiple queries
the limit is high
enrichments are requested

Input Schema

TableJSON Schema

Name	Required	Description
`skip`	No	Skip places count.
`async`	No	Deprecated compatibility flag. Prefer execution_mode.
`limit`	No	Organizations per query limit.
`query`	Yes	One or more Google Maps queries or place ids.
`fields`	No	Specific place fields to return.
`region`	No	Region code, for example us.
`webhook`	No	Optional webhook URL for async completion.
`language`	No	Language code, for example en.
`enrichment`	No	Optional enrichment names supported by Outscraper.
`coordinates`	No	Optional latitude,longitude coordinates bias supported by Outscraper.
`execution_mode`	No	Execution strategy. Use auto to let the MCP server choose between sync and async.
`drop_duplicates`	No	Drop duplicate places across results.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`meta`	Yes
`async`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.2.5Sep 23, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv0.2.3Aug 1, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Since no annotations are provided, the description carries the full burden. It mentions async submissions, enrichments, execution_mode choice, and implicitly indicates read-only behavior by being a search. It also notes the absence of cursor pagination (in contrast to businesses_search). However, it does not explicitly state the return format or side effects, but the output schema covers return structure. Overall, it offers solid behavioral context.

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?

The description is moderately long but well-structured with bullet points, making it scannable and front-loaded with the primary purpose. Each bullet adds distinct guidance without repeating schema info. It earns its length by covering usage scenarios and alternatives.

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?

Given the tool's complexity (12 params, output schema present), the description comprehensively covers usage scenarios, alternatives, and execution mode guidance. It lacks authentication or error mention, but those are likely implicit in a search tool. The output schema handles return details, so the description is sufficiently complete for an agent to select and invoke correctly.

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%, so every parameter is already documented. The description adds usage context (e.g., 'Google Maps-style queries', execution_mode triggers) but does not provide parameter-specific details beyond the schema. Baseline of 3 is appropriate as 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?

The description clearly states 'Search Google Maps places through Outscraper' and differentiates from the sibling tool businesses_search by emphasizing direct Google Maps search pipeline vs normalized filters. It specifies use cases like 'ad hoc place discovery' and distinguishes itself from alternatives explicitly.

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

Usage Guidelines5/5

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

The description provides explicit 'Prefer this tool when' and 'Use businesses_search instead when' conditions, and further guides on execution_mode='auto' with specific triggers. This is excellent routing information that leaves no ambiguity about when to choose this tool over siblings.

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