Google Maps MCP Server
This MCP server lets you search Google Maps and retrieve structured place details for AI/LLM clients.
Search Google Maps for businesses, landmarks, points of interest, and services using a free-text query that can include category/name and location.
Limit results from 1 to 50 (default 10) and localize searches with ISO country and language codes.
Get structured place data: name, Google Place ID, category, address, phone/international phone, website/domain, latitude/longitude, rating, review count, and Google Maps URL.
Fetch details for a single place by Google Place ID or exact business/landmark name, with country/language localization.
Connect from MCP clients over stdio or Streamable HTTP without an API key, billing account, or browser automation.
Provides tools for searching businesses, attractions, and services on Google Maps, retrieving structured place details including ratings, contact info, coordinates, and Google Maps URLs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Google Maps MCP ServerFind me the top-rated pizza places in Brooklyn"
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.
gmaps-mcp
Google Maps MCP server for AI agents and LLM applications.
Purpose
gmaps-mcp is an open-source Google Maps MCP server and command line interface built on the Model Context Protocol. It provides an AI agent maps tool that requires no API key, billing account, or browser automation setup.
AI assistants in Claude Desktop, Cursor, Cline, Windsurf, Zed, and OpenCode connect to this Model Context Protocol Google Maps server to search local businesses, inspect reviews and star ratings, find phone numbers and websites, and retrieve geographic coordinates. The tool runs locally through standard input/output (stdio) or across networks through Streamable HTTP.
Related MCP server: Google Maps MCP Server
Architecture
The system has four core layers:
Protocol layer. Built with the official MCP Python SDK (
mcp.server.mcpserver.MCPServer). Exposes tools and resources over stdio or Streamable HTTP transports. Server logging writes strictly to stderr so stdout remains clean JSON-RPC for MCP clients.Scraper engine. Built on
aiohttpandphonenumbers. The engine queries Google Maps endpoints directly with asynchronous HTTP requests, parses raw response payloads, extracts place records, and normalizes phone numbers into E.164 format. It runs without Playwright, Puppeteer, or browser binaries.Geospatial grid tiling. When searching broad areas or entire cities, the grid crawler calculates the geographic bounding box and subdivides the region into smaller viewport tiles. This bypasses the standard 20-result pagination cap of Google Maps and collects hundreds of places per query.
Storage and delivery layer. When result sets exceed normal prompt budgets, the server stores full result objects in memory and returns an MCP resource URI (
gmaps://results/{resource_id}). Clients fetch the complete payload through the MCP resource interface, preventing context window exhaustion.
Setup
Requirements
Python 3.10 or higher
uvpackage manager (recommended) orpip
Install and run with uvx
Run the server directly without cloning:
uvx --from git+https://github.com/devsanthoshmk/gmaps-mcp.git gmaps-mcp serveInstall from source
Clone the repository and install dependencies with uv:
git clone https://github.com/devsanthoshmk/gmaps-mcp.git
cd gmaps-mcp
uv syncUsage
Run as an MCP server
Start the server using stdio transport (default):
uv run gmaps-mcp serveStart the server using Streamable HTTP transport:
uv run gmaps-mcp serve --transport streamable-http --host 127.0.0.1 --port 8000Run via command line
Search places
Search for places and display a formatted table:
uv run gmaps-mcp search "dentists" "Chicago" --limit 10 --country us --format tableSearch across an entire city using geospatial grid tiling:
uv run gmaps-mcp search "bakeries" "Paris" --country fr --grid --format tableExport search results to CSV or JSON:
uv run gmaps-mcp search "pharmacies" "Chennai" --grid --country in --output pharmacies.csv
uv run gmaps-mcp search "coffee shops" "Seattle" --country us --output coffee.jsonGet place details
Look up details by Google Place ID:
uv run gmaps-mcp details "ChIJ7xiFY1VmUjoR2IuH0fYWMlk" --format tableLook up details by name and export to CSV:
uv run gmaps-mcp details "Eiffel Tower Paris" --country fr --output eiffel.csvConfiguration
Claude Desktop
To configure Claude Desktop MCP Maps integration, add gmaps-mcp to claude_desktop_config.json:
{
"mcpServers": {
"google-maps": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/devsanthoshmk/gmaps-mcp.git",
"gmaps-mcp",
"serve"
]
}
}
}Config file paths by platform:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json
Cursor
Add to .cursor/mcp.json or your global Cursor MCP configuration:
{
"mcpServers": {
"google-maps": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/devsanthoshmk/gmaps-mcp.git",
"gmaps-mcp",
"serve"
]
}
}
}Windsurf, Cline, and Zed
Add to your client MCP configuration:
{
"mcpServers": {
"google-maps": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/devsanthoshmk/gmaps-mcp.git",
"gmaps-mcp",
"serve"
]
}
}
}Install with mcp-add
Add the server using the mcp-add utility:
npx mcp-add -n google-maps -t stdio -c "uvx --from git+https://github.com/devsanthoshmk/gmaps-mcp.git gmaps-mcp serve"Local development configuration
Point an MCP client to a local repository checkout:
{
"mcpServers": {
"google-maps": {
"command": "uv",
"args": [
"run",
"--directory",
"/absolute/path/to/gmaps-mcp",
"gmaps-mcp",
"serve"
]
}
}
}Available tools
The server registers two MCP tools:
search_google_maps
Searches Google Maps for businesses, places, and points of interest.
Parameter | Type | Default | Description |
| string | required | Search query or business category such as "coffee shops" or "dentists" |
| string | required | City, neighborhood, or landmark such as "Paris", "Chicago", or "Chennai" |
| integer | null | Maximum number of results to return |
| boolean | false | Enable geospatial grid tiling for large area coverage |
| string | "in" | ISO 3166-1 alpha-2 country code such as "us", "fr", or "in" |
| string | "en" | Response language code |
| "inline" | "resource" | "inline" | Delivery mode. Use "resource" to prevent large result sets from filling the context window |
get_place_details
Fetches structured details for a specific place.
Parameter | Type | Default | Description |
| string | required | Google Place ID (e.g. "ChIJ...") or exact business name |
| string | "in" | ISO 3166-1 alpha-2 country code |
| string | "en" | Response language code |
Output schema
Places return structured JSON matching this schema:
{
"place_id": "ChIJ7xiFY1VmUjoR2IuH0fYWMlk",
"name": "New Chennai Pharmacy",
"category": "Pharmacy",
"address": "No. 33, Sarojini Street, T.Nagar, Chennai, Tamil Nadu 600017",
"phone": "091500 97960",
"international_phone": "+91 91500 97960",
"website": "https://example.com",
"domain": "example.com",
"latitude": 13.0371485,
"longitude": 80.2319365,
"rating": 4.7,
"review_count": 25,
"google_maps_url": "https://www.google.com/maps/place/?q=place_id:ChIJ7xiFY1VmUjoR2IuH0fYWMlk"
}Development
Run the test suite:
uv run --extra dev pytestLicense
MIT license in LICENSE.
Available Tools
2 toolsget_place_detailsA
Retrieve detailed information for a single specific Google Maps place or business. Looks up a place using its unique Google Place ID (e.g., 'ChIJ...' or 'place_id:ChIJ...') or specific landmark/business name. Returns complete structured details including address, phone number, website, rating, coordinates, and Google Maps URL.
| Name | Required | Description | Default |
|---|---|---|---|
| place | Yes | The place identifier to fetch details for. Can be either: 1. A Google Place ID (e.g., 'ChIJ12k5kG_iDDkRwuzibQwYZ4M' or 'place_id:ChIJ...') 2. An exact place / business name and location (e.g., 'AIIMS New Delhi' or 'Taj Mahal Palace Mumbai'). | |
| country | No | Two-letter ISO country code for region localization (default: 'in'). | in |
| language | No | Language code for the response (default: 'en'). | en |
Output Schema
| Name | Required | Description |
|---|---|---|
| found | No | Whether the place was successfully found |
| place | No | The retrieved place object if found, otherwise null |
| query_or_id | Yes | The place query or Place ID searched for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the lookup behavior (by ID or name) and the return fields (address, phone, etc.), but does not mention rate limits, authentication requirements, or what happens if the place is not found. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and each sentence adds essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the key purpose, parameter usage, and return value hints. The presence of an output schema reduces the need to describe return values. Minor gaps exist (e.g., error behavior), but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the two formats for the 'place' parameter (Google Place ID vs. name/location), which goes beyond the schema's description. This additional context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'retrieve' and the resource 'detailed information for a single specific Google Maps place or business'. It distinguishes from sibling tool 'search_google_maps' by emphasizing single-place lookup vs. searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (to get details for a known place via ID or name) and implicitly distinguishes from searching. It does not explicitly state when not to use it or mention alternatives beyond the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_google_mapsA
Search Google Maps for local businesses, places, points of interest, and services. Returns structured place data including business name, Google Place ID, category, formatted street address, phone numbers, website URL, geo-coordinates (latitude/longitude), star rating, total review count, and direct Google Maps URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of place results to return (between 1 and 50, default is 10). | |
| query | Yes | The search query for Google Maps. Can be a business category, specific place name, service, or landmark along with a location. Examples: 'coffee shops in Koramangala Bangalore', 'dentists near Connaught Place Delhi', 'Italian restaurants in Bandra Mumbai', 'hospitals in Hyderabad', 'electricians near Indiranagar', 'museums in London'. | |
| country | No | Two-letter ISO 3166-1 alpha-2 country code to localize search results and map boundaries. Default is 'in' (India). Other examples: 'us' (United States), 'gb' (United Kingdom), 'ca' (Canada), 'au' (Australia), 'de' (Germany), 'fr' (France), 'sg' (Singapore), 'ae' (UAE). | in |
| language | No | Language code for the results (e.g. 'en' for English, 'hi' for Hindi, 'es' for Spanish, 'fr' for French, 'de' for German, 'ja' for Japanese). Default is 'en'. | en |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | The search query that was executed |
| places | No | List of matched Google Maps places |
| country | Yes | The ISO 3166-1 alpha-2 country code used (e.g., 'in', 'us') |
| language | Yes | The language code used for results (e.g., 'en', 'hi') |
| total_results | Yes | Number of places returned in this response |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states it returns structured place data listing 10 fields, which is helpful. However, it does not disclose potential rate limits, API quota implications, or any constraints on search frequency or result freshness. The behavioral disclosure is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main action. It then lists the return fields, which is useful but slightly verbose for a search tool. It earns its place without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (4 params, 1 required, no nested objects) and presence of an output schema, the description is fairly complete. It explains the search scope and return fields. It could be improved by noting that results are limited by Google's ranking (not just the limit parameter) and how to formulate effective queries beyond the examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no parameter-level detail beyond what the schema already provides. It lists the return fields but not how parameters affect them. Since the schema is already thorough, no penalty is applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Search') and resources ('Google Maps for local businesses, places, points of interest, and services'), clearly distinguishing it from its sibling tool 'get_place_details' which would provide details on 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for broad searches (businesses, places, POIs), and the sibling tool name 'get_place_details' suggests the alternative for specific place info. However, no explicit when-to-use or when-not-to-use guidance is provided.
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.
2 tool updates
v0.1.0- First observed
get_place_details - First observed
search_google_maps
TDQS
Scored across 2 tools
The two tools have distinct purposes: search_google_maps finds places by query, and get_place_details retrieves details for a known place ID. There is slight overlap in the returned fields, but the use cases are clearly different.
Both tools use a clear verb_noun pattern (search/get + google_maps/place_details). The naming is consistent, though 'get_place_details' could be more symmetrical as 'get_google_maps_place' for perfect parity.
Only two tools for a Google Maps server is very limited. Maps APIs typically support additional operations like directions, geocoding, or place photos, so the tool count feels too small for the implied scope.
The core search and detail retrieval are present, but critical operations like navigation (directions), geocoding (address to coordinates and reverse), and place photo fetching are missing, creating significant gaps for common map-related tasks.
Maintenance
Related MCP Connectors
Live Google Maps business search, review, and photo data for AI agents over MCP.
Routing, geocoding, places, matrix and map tools for location-aware AI workflows.
Google SERP, Maps, Shopping, News and AI-answer data for AI agents, from the Searlo search API.
Real-time Google Maps local business leads, reviews, places & emails MCP. OAuth or API key.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables 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.22MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to access Google Maps services including places search, details, directions, geocoding, and nearby search through natural language.62MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI assistants to search and scrape Google Maps places data (name, rating, address, etc.) directly without an API key.1-
- AlicenseNot gradedqualityCmaintenanceProvides Google Maps business search, single-place lookup, and multi-mode travel directions without an API key, enabling coding tools to pull Maps data directly into conversations.MIT