Which integrations are available for this server?

Provides tools for searching Google Maps places, retrieving place details, reviews, photos, business posts, and contributor review histories without requiring API keys.

How do I use Google Maps MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Google Maps MCP Server Find top-rated sushi restaurants in San Francisco and show their reviews" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Google Maps MCP Server

by adityak74

Overview Schema Related Servers Score Discussions

Python

Local

Google Maps MCP Server

Quick Start • Features • Tool Reference • Client Setup • Architecture • Contributing

🌟 Features

🆓 100% Free & Open Source: No Google Cloud project, no Google Places API billing, and no third-party subscription keys (like HasData) required.
⚡ Built on Latest FastMCP 4.0: Full compliance with the official Model Context Protocol specifications (stdio & streamable HTTP).
🧩 Complete HasData Schema Parity: Standardized JSON data output matching HasData's Google Maps tool contracts (localResults, placeResults, reviews, topics, photos, posts, contributor).
🛡️ Anti-Bot & Stealth Engine: Automatic GDPR / cookie consent dismissal, user-agent emulation, and WebGL canvas stealth to prevent automated session blocking.
🎯 Direct Place & Query Resolution: Gracefully resolves both broad regional keyword searches and direct place URL / single-business matches.
🍪 Optional Session Persistence: Full support for STORAGE_STATE / cookies to bypass Google Maps "Limited View" restrictions for signed-in sessions.

Related MCP server: Local Business Data MCP Server

⚖️ How It Compares

Feature	Official Google Places API	HasData MCP (Hosted)	This Open Source MCP
Price	Paid (Pay per call / Google Cloud)	Paid (HasData subscription / credits)	100% Free
API Keys Required	Yes (GCP Project & Billing)	Yes (`HASDATA_API_KEY`)	None
Source Code	Closed	Closed Source (Hosted endpoint only)	Full MIT Open Source
FastMCP Version	Custom / Older	Remote Proxy	FastMCP 4.0+ Native
Review Topics & Clustering	❌ (Limited)	✅ Yes	✅ Yes
Contributor Review History	❌ No	✅ Yes	✅ Yes
Self-Hosted Privacy	❌ Hosted by Google	❌ Proxy through HasData	✅ Runs locally on your machine

🏗️ Architecture

flowchart LR
    subgraph Client["MCP Client (Claude Desktop / Cursor / Claude Code)"]
        LLM[LLM / Chat Model]
    end

    subgraph MCP["Google Maps MCP Server (FastMCP 4.0)"]
        Router[FastMCP Tool Router]
        Models[Pydantic HasData Schemas]
        
        subgraph Extractors["Async Extractors"]
            E1[search_places]
            E2[get_place_details]
            E3[get_place_reviews]
            E4[get_place_photos]
            E5[get_place_posts]
            E6[get_contributor_reviews]
        end
        
        BrowserMgr[BrowserManager Singleton]
    end

    subgraph Web["Google Maps"]
        GMap[(Google Maps Live Web)]
    end

    Client <-->|stdio / JSON-RPC| Router
    Router --> Extractors
    Extractors --> Models
    Extractors <--> BrowserMgr
    BrowserMgr <-->|Playwright Chromium Stealth| GMap

🚀 Quick Start

1. Installation via `uv`

We recommend uv for fast, isolated Python execution.

# Clone the repository
git clone https://github.com/adityak74/google-maps-mcp.git
cd google-maps-mcp

# Install dependencies and Chromium browser
uv sync
uv run playwright install chromium

2. Verify Installation

Run the test suite to ensure everything is operating cleanly:

uv run pytest -v

💻 Client Configuration

Claude Desktop

Add the server to your claude_desktop_config.json (~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "google-maps": {
      "command": "uv",
      "args": [
        "--directory",
        "/ABSOLUTE/PATH/TO/google-maps-mcp",
        "run",
        "google-maps-mcp"
      ]
    }
  }
}

Cursor

Add to your project's .cursor/mcp.json:

{
  "mcpServers": {
    "google-maps": {
      "command": "uv",
      "args": [
        "--directory",
        "/ABSOLUTE/PATH/TO/google-maps-mcp",
        "run",
        "google-maps-mcp"
      ]
    }
  }
}

Claude Code CLI

claude mcp add google-maps -- uv --directory /ABSOLUTE/PATH/TO/google-maps-mcp run google-maps-mcp

Windsurf / Codeium

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "google-maps": {
      "command": "uv",
      "args": [
        "--directory",
        "/ABSOLUTE/PATH/TO/google-maps-mcp",
        "run",
        "google-maps-mcp"
      ]
    }
  }
}

🛠️ Tool Reference

All 6 tools return clean, structured JSON conforming to HasData's schema definitions.

1. `google_maps_search`

Search Google Maps for places matching a keyword query, ranked as Google Maps ranks them.

Parameters:
- q (str, required): Search term (e.g. "best coffee in Seattle", "plumber near me").
- ll (str, optional): Geographic center pin and zoom as @lat,lng,zoomz (e.g. "@47.6062,-122.3321,14z").
- hl (str, optional, default: "en"): Two-letter interface language code.
- gl (str, optional, default: "us"): Two-letter country region code.
- start (int, optional, default: 0): Pagination offset.

{
  "localResults": [
    {
      "position": 1,
      "title": "Taj Palace",
      "address": "92 THF Blvd, Chesterfield, MO 63005",
      "rating": 4.4,
      "phone": "(636) 728-1000",
      "type": "Indian restaurant",
      "website": "https://tajpalacestl.com/",
      "gpsCoordinates": { "latitude": 38.6671397, "longitude": -90.5892454 }
    }
  ],
  "pagination": { "start": 0, "count": 1, "hasMore": false }
}

2. `google_maps_place_details`

Retrieve comprehensive listing information for a specific place.

Parameters:
- placeId (str, optional): Google Maps place identifier or direct place URL.
- dataId (str, optional): Feature data ID (hex representation).
- query (str, optional): Fallback search query if ID is not known.
- hl (str, optional, default: "en"): Language code.

{
  "placeResults": {
    "title": "Taj Palace",
    "address": "92 THF Blvd, Chesterfield, MO 63005",
    "rating": 4.4,
    "phone": "(636) 728-1000",
    "type": "Indian restaurant",
    "website": "https://tajpalacestl.com/",
    "images": [
      "https://lh5.googleusercontent.com/p/AF1Qip...=w400-h300-k-no"
    ]
  }
}

3. `google_maps_reviews`

Scrape the review feed for a place with sorting, review topics, and pagination.

Parameters:
- placeId (str, optional): Place ID or URL.
- dataId (str, optional): Feature data ID.
- sortBy (str, optional, default: "mostRelevant"): "mostRelevant", "newestFirst", "ratingHigh", or "ratingLow".
- topicId (str, optional): Filter reviews mentioning a specific topic chip.
- num (int, optional, default: 20): Maximum number of reviews to extract.

{
  "placeInfo": { "title": "Taj Palace" },
  "topics": [
    { "id": "lunch_buffet", "keyword": "lunch buffet", "mentions": 42 },
    { "id": "chicken_tikka", "keyword": "chicken tikka", "mentions": 28 }
  ],
  "reviews": [
    {
      "rating": 5.0,
      "snippet": "Outstanding Indian food and attentive service!",
      "date": "2 weeks ago",
      "user": { "name": "Sarah Miller", "contributorId": "106033685843245983748" },
      "response": { "snippet": "Thank you Sarah, we hope to see you again soon!" }
    }
  ]
}

4. `google_maps_photos`

Retrieve photo feeds categorized by section (All, Menu, Atmosphere, Inside, etc.).

Parameters:
- placeId (str, optional) / dataId (str, optional).
- categoryId (str, optional): Category tab filter (e.g. "Menu").
- limit (int, optional, default: 20): Maximum photos to return.

{
  "categories": ["All", "Menu", "Inside", "Vibe"],
  "photos": [
    {
      "image": "https://lh5.googleusercontent.com/p/AF1Qip...=w1080-h720",
      "thumbnail": "https://lh5.googleusercontent.com/p/AF1Qip...=w400-h300"
    }
  ]
}

5. `google_maps_posts`

Retrieve updates, announcements, offers, and posts published by the business listing.

Parameters:
- placeId (str, optional) / dataId (str, optional).
- limit (int, optional, default: 10): Maximum posts to return.

{
  "posts": [
    {
      "snippet": "Join us for our Weekend Grand Buffet starting this Saturday at 11:30 AM!",
      "date": "3 days ago"
    }
  ]
}

6. `google_maps_contributor_reviews`

Retrieve reviews written by a specific reviewer across all locations they evaluated. Ideal for reviewer credibility and local guide network analysis.

Parameters:
- contributorId (str, required): Contributor ID or profile link.
- num (int, optional, default: 20): Maximum reviews to return.

{
  "contributor": {
    "name": "David Kim",
    "level": "Level 6 Local Guide",
    "points": 1450,
    "contributions": "Level 6 Local Guide · 1,450 points"
  },
  "reviews": [
    {
      "placeInfo": { "title": "Artisan Bakery" },
      "rating": 5.0,
      "snippet": "Best sourdough loaf in town.",
      "date": "1 month ago"
    }
  ]
}

🔒 Advanced: Authentication & Google Maps Limited View

In 2024–2026, Google introduced a "Limited View" for unauthenticated browser sessions in certain geographical regions or unverified IPs. In this mode, Google temporarily restricts public review feeds behind a sign-in prompt.

To bypass this restriction and access full review feeds unconditionally:

Save Authenticated Cookies / Storage State: Use Playwright CLI to log into your Google account once and export your cookies:
```
uv run playwright codegen --save-storage=google_state.json https://www.google.com/maps
```

Pass Environment Variable: Provide the path to STORAGE_STATE in your client config or shell:

export STORAGE_STATE="/absolute/path/to/google_state.json"

Or inside your MCP client config:

"env": {
  "STORAGE_STATE": "/absolute/path/to/google_state.json"
}

🧪 Testing & Development

Run all test suites including models, utilities, extractors, and server tool registrations:

# Run pytest with coverage/verbose reporting
uv run pytest -v

# Run only extractor DOM tests
uv run pytest tests/test_extractors.py -v

# Run in headed mode for visual browser debugging
HEADLESS=false uv run pytest tests/test_browser.py -v

🤝 Contributing

Contributions, issues, and feature requests are welcome! Feel free to check the issues page.

Fork the Project
Create your Feature Branch (git checkout -b feature/AmazingFeature)
Commit your Changes (git commit -m 'feat: add some amazing feature')
Push to the Branch (git push origin feature/AmazingFeature)
Open a Pull Request

📄 License

Distributed under the MIT License. See LICENSE for more information.

Available Tools

6 tools

google_maps_contributor_reviewsGoogle Maps Contributor ReviewsA

Retrieve reviews written by a specific reviewer across all places they rated.

ParametersJSON Schema

Name	Required	Description	Default
`hl`	No	Two-letter language code (default: 'en').	en
`num`	No	Number of reviews to return (default: 20).
`contributorId`	Yes	The contributorId or Google Maps profile link.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/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 of behavioral disclosure. It only states the basic read operation and scope; there is no mention of pagination, ordering, error cases, or whether contributorId can be a profile link rather than an ID. It is a minimal functional statement with no extra 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.

Conciseness5/5

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

The description is a single clear sentence that front-loads the action and object. There is no redundant phrasing, and every word contributes to understanding the tool's purpose.

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?

The tool is simple: one required parameter, no enums, no nested objects, and an output schema is available. The concise scope statement is largely sufficient for invoking the tool correctly. It lacks usage-alternative guidance and deeper behavioral caveats, but those are not critical given the schema and low 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%, so the schema already documents all three parameters including defaults for hl and num. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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 uses a specific verb ('retrieve'), names the resource ('reviews written by a specific reviewer'), and defines the scope ('across all places they rated'). This clearly distinguishes it from sibling tools like google_maps_reviews, which presumably returns reviews for a specific place.

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 the use case: use this tool when you need a reviewer's reviews across multiple places. However, it does not explicitly state when to use this tool versus alternatives like google_maps_reviews, nor does it mention any exclusions or trade-offs.

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

google_maps_photosGoogle Maps PhotosC

Retrieve the photo feed for a place.

ParametersJSON Schema

Name	Required	Description	Default
`hl`	No	Two-letter language code (default: 'en').	en
`limit`	No	Maximum number of photos to return (default: 20).
`dataId`	No	The dataId of the place.
`placeId`	No	The placeId or Google Maps place URL.
`categoryId`	No	Category filter (e.g. 'All', 'Menu', 'Inside').

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

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

The description is a single 'retrieve' statement and does not disclose behavioral traits such as identifier requirements, empty-result behavior, pagination, or read-only guarantees. Since no annotations are provided, the description carries the full burden of behavioral disclosure and falls short. It does not contradict any annotation, but it adds little beyond what the tool name already implies.

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 a single, front-loaded sentence with no filler, repetition, or redundant phrasing. It is efficient and readable, though it sacrifices some behavioral and usage context for brevity. Every word earns its place.

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?

For a read-only tool with a complete output schema and fully documented parameters, the one-sentence description is minimally viable: it names the resource and lets the schema handle invocation details. However, it lacks guidance for choosing among sibling photo/review/post tools and offers no behavioral caveats. An agent could likely call it correctly with placeId, but not optimally in all contexts.

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?

All five parameters are fully documented in the schema with 100% coverage, so the description does not need to repeat them. The description adds no extra meaning about how dataId, placeId, or categoryId interact, but the schema already provides that information. The baseline of 3 applies because the schema carries the parameter semantics.

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 uses a specific verb ('Retrieve') and a concrete resource ('the photo feed for a place'), which clearly distinguishes it from sibling tools like google_maps_search, google_maps_reviews, and google_maps_posts. It does not explicitly state scope details like category filtering, but the schema covers that. Overall, an agent can tell what this tool does without opening the schema.

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 provides no guidance on when to use this tool versus alternatives such as google_maps_reviews, google_maps_posts, or google_maps_contributor_reviews. There are no exclusions, conditions, or hints about which sibling tool to choose for non-photo content. The only implied context is 'for a place,' which is too thin to route an agent reliably.

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

google_maps_place_detailsGoogle Maps Place DetailsA

Get one place in full by placeId, dataId, or search query.

ParametersJSON Schema

Name	Required	Description	Default
`hl`	No	Two-letter language code (default: 'en').	en
`query`	No	Fallback search query or name of the place.
`dataId`	No	The dataId from a search result (e.g. 0x...:0x...).
`placeId`	No	The placeId from a search result or a Google Maps URL.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations exist, so the description carries the behavioral disclosure burden. 'Get' implies a read-only fetch and 'in full' suggests comprehensive detail, but the description does not explain what happens when multiple identifiers are supplied, whether query performs a lookup and picks the top result, or what 'full' excludes (e.g., reviews/photos are separate tools). This is a notable gap but the core read behavior is communicated.

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

Conciseness5/5

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

One tight sentence that front-loads the verb and resource, followed by a compact list of input options. Every word earns its place with zero redundancy or filler.

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?

The tool has four optional parameters and no required fields, yet the description does not tell the agent that at least one lookup key must be provided, nor how to prioritize between placeId, dataId, and query. The output schema covers return values, but the description alone leaves the invocation rules underspecified.

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 the parameters are fully documented in the schema. The description reinforces the three lookup keys but adds no syntax, format, or precedence information beyond what the schema already provides. Baseline 3 applies.

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 states a specific verb ('Get'), a clear resource ('one place in full'), and the three lookup methods (placeId, dataId, search query). This sharply distinguishes it from sibling tools like google_maps_search (which returns multiple results) and google_maps_reviews/photos/posts (which return sub-resources).

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

Usage Guidelines4/5

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

The description provides clear context: use this when you need full details for a single place and already have a placeId, dataId, or can supply a search query. It does not explicitly name alternatives or exclusions, but the sibling list and tool name make the use case obvious.

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

google_maps_postsGoogle Maps PostsB

Retrieve the business's own posts, announcements, and updates on Google Maps.

ParametersJSON Schema

Name	Required	Description	Default
`hl`	No	Two-letter language code (default: 'en').	en
`limit`	No	Maximum number of posts to return (default: 10).
`dataId`	No	The dataId of the place.
`placeId`	No	The placeId or Google Maps place URL.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the full burden for behavioral disclosure. It only states 'Retrieve', implying a read operation, but provides no details about pagination, limits, authorization, or what distinguishes posts from other content. There is no contradiction, but the information is minimal.

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

Conciseness5/5

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

The description is a single sentence with no filler. The key verb and object are front-loaded, and it earns its place by clarifying the exact scope of the tool.

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?

The output schema covers return values, but the description leaves a meaningful gap: there are two optional identifier parameters (dataId and placeId) yet no guidance on whether at least one is required or how they interact. For a tool with this simplicity, the minimal description is adequate but not fully complete.

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 the baseline is 3. The description itself adds no parameter-level meaning, but the schema already documents each parameter (hl, limit, dataId, placeId) adequately.

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 uses a specific verb ('Retrieve') and a particular resource ('the business's own posts, announcements, and updates'). The qualifier 'own' clearly separates this from sibling tools like reviews and photos, so an agent can identify the right tool without opening the schema.

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 gives no guidance on when to use this tool over alternatives, nor any exclusions or prerequisites. It does not mention that dataId or placeId must be provided, nor when to prefer this over google_maps_reviews or google_maps_photos.

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

google_maps_reviewsGoogle Maps ReviewsC

Retrieve the review feed for a place with sorting and topic filtering.

ParametersJSON Schema

Name	Required	Description	Default
`hl`	No	Two-letter language code (default: 'en').	en
`num`	No	Maximum number of reviews to extract (default: 20).
`query`	No	Place name fallback if ID is not available.
`dataId`	No	The dataId of the place.
`sortBy`	No	Sort order: 'mostRelevant', 'newestFirst', 'ratingHigh', or 'ratingLow'.	mostRelevant
`placeId`	No	The placeId or Google Maps place URL.
`topicId`	No	Filter to one topic using a keyword from the topics array.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/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 of behavioral disclosure. It conveys that the operation is a retrieval and mentions sorting and topic filtering capabilities, but it says nothing about identifier precedence among the three optional identifiers (dataId, placeId, query), fallback resolution, or read-safety guarantees, leaving important behavior undisclosed.

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?

A single 13-word sentence that is front-loaded with the verb and resource and wastes no words. It is efficient, but the brevity comes at the expense of usage guidance and behavioral depth, making it slightly under-sized for a 7-parameter tool with five siblings.

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

Completeness2/5

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

The output schema covers return values and the input schema covers parameters at 100%, so those gaps are closed by structured data. However, with no annotations and five siblings including a near-duplicate (google_maps_contributor_reviews), the 13-word description is too thin to let an agent confidently select and invoke the tool; it lacks usage differentiation and behavioral 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%, so the input schema already documents all seven parameters with defaults and relationships (e.g., query as 'fallback if ID is not available'). The description adds no parameter-level detail beyond pointing at sorting and topic filtering, which map directly to sortBy and topicId, so the baseline 3 applies.

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 specific verb ('Retrieve') and resource ('review feed for a place'), and adds capability modifiers (sorting, topic filtering) that tell the agent what the tool can do. The phrase 'for a place' implies a distinction from the google_maps_contributor_reviews sibling, but that differentiation is implicit rather than explicitly named, so it stops short of a 5.

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 guidance on when to use this tool versus alternatives, a notable gap given five siblings including the closely related google_maps_contributor_reviews and google_maps_place_details. No when-to-use, when-not-to-use, or alternative routing is provided; the agent must infer the use case from the single phrase 'for a place.'

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

google_maps_searchGoogle Maps SearchA

Search Google Maps for places matching a query. Ranked as Google Maps ranks them.

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	Search query (e.g., 'coffee in Seattle', 'plumber near me').
`gl`	No	Two-letter country code (default: 'us').	us
`hl`	No	Two-letter language code (default: 'en').	en
`ll`	No	Map center and zoom as '@lat,lng,zoomz' (e.g., '@47.6062,-122.3321,14z').
`start`	No	Result offset for paging (default: 0).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

There are no annotations, so the description carries the behavioral burden. It discloses the useful ranking behavior ('Ranked as Google Maps ranks them') and 'Search' implies a read-only lookup, but it does not address potential limitations, result scope, or any external API constraints. Still, it provides some meaningful behavioral context beyond the bare schema.

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

Conciseness5/5

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

The description is two short sentences with no wasted words. The core action is front-loaded, and the second sentence adds a distinct behavioral detail rather than repeating the tool name or schema.

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 an output schema present and full parameter documentation in the input schema, the description is sufficient for a basic search tool. It could optionally mention how to proceed to details or reviews, but the sibling tool names supply that 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?

The input schema already describes all five parameters with 100% coverage, including defaults for gl, hl, ll, and start. The description adds no parameter-level detail, which is acceptable because the schema carries the semantic weight.

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 the tool's action ('Search Google Maps') and its object ('places matching a query'), distinguishing it from sibling tools that fetch details, reviews, photos, or posts. The added note about ranking as Google Maps ranks them further clarifies the expected result ordering.

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

Usage Guidelines4/5

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

The description makes the primary use case clear: find places by query. It does not explicitly mention when not to use it or point to alternatives like place_details, but the search-specific wording and sibling tool names imply the appropriate context without ambiguity.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Sep 6, 2026
- First observedgoogle_maps_contributor_reviews
- First observedgoogle_maps_photos
- First observedgoogle_maps_place_details
- First observedgoogle_maps_posts
- First observedgoogle_maps_reviews
- First observedgoogle_maps_search

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a distinct aspect of Google Maps data: place search, individual place details, reviews, photos, posts, and contributor review history. Even though place_details can accept a query, its purpose as a single-place lookup is clearly separated from the ranked search tool.

Naming Consistency4/5

All tools share the google_maps_ prefix and use snake_case, making the namespace cohesive. Some names are noun-based (reviews, photos, posts) while others are verb- or resource-oriented, but the overall pattern is predictable and readable.

Tool Count5/5

Six tools is a well-scoped set for a Google Maps place-data server. Each tool covers a meaningful, distinct retrieval use case without unnecessary overlap or bloat.

Completeness3/5

The set thoroughly covers place discovery and place-specific content feeds, but notable Google Maps capabilities like geocoding, directions, and place autocomplete are missing. As a read-only place information server it is fairly complete, but as a general Google Maps MCP server it has gaps.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Google Maps Scraper
com.gmapsextractor
Live Google Maps business search, review, and photo data for AI agents over MCP.
Web Scraping Location Services
21
HasData Google MapsOAuth
com.hasdata
Google Maps places, reviews, contributor history, photos and posts as JSON. No Google Cloud.
Location Services Web Scraping
16
mcp A
com.googleapis.mapstools
Ground your AI applications with trusted geospatial data from Google Maps.
Location Services Search AI & Machine Learning
52
Buscador Google A
io.github.mcp-dir
Search Google straight from your AI agent. Web results, images, videos, news, products, scholarly ar
Search Browser Automation
181

Related MCP Servers

Google Maps MCP Server
Location Services Search
iceener
F
license
Not graded
quality
C
maintenance
Enables location-aware AI agents to search for nearby places, get detailed place information including hours and ratings, and calculate routes with turn-by-turn directions using Google Maps APIs.
Updated a month ago (2026-07-27 13:22 UTC)
22
-
Local Business Data MCP Server
Location Services Search
BACH-AI-Tools
A
license
B
quality
D
maintenance
Enables access to Google Maps business data including search, reviews, photos, and geocoding. Supports searching businesses by location, area, or coordinates, retrieving detailed business information, reviews, and performing reverse geocoding operations.
Updated 9 months ago (2025-12-07 20:33 UTC)
13
MIT
Google Maps MCP Server
Location Services Search Travel & Transportation
arthurkatcher
A
license
A
quality
B
maintenance
Enables AI assistants to access Google Maps services including places search, details, directions, geocoding, and nearby search through natural language.
Updated 4 months ago (2026-05-04 08:04 UTC)
6
2
MIT
maps-scrapper
Web Scraping Browser Automation Location Services
rahul-bhatt43
F
license
Not graded
quality
C
maintenance
Enables AI assistants to search and scrape Google Maps places data (name, rating, address, etc.) directly without an API key.
Updated a month ago (2026-08-10 05:14 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/adityak74/google-maps-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Google Maps MCP Server

🌟 Features

⚖️ How It Compares

🏗️ Architecture

🚀 Quick Start

1. Installation via uv

2. Verify Installation

💻 Client Configuration

Claude Desktop

Cursor

Claude Code CLI

Windsurf / Codeium

🛠️ Tool Reference

1. google_maps_search

2. google_maps_place_details

3. google_maps_reviews

4. google_maps_photos

5. google_maps_posts

6. google_maps_contributor_reviews

🔒 Advanced: Authentication & Google Maps Limited View

🧪 Testing & Development

🤝 Contributing

📄 License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. Installation via `uv`

1. `google_maps_search`

2. `google_maps_place_details`

3. `google_maps_reviews`

4. `google_maps_photos`

5. `google_maps_posts`

6. `google_maps_contributor_reviews`