Skip to main content
Glama
arthurkatcher

Google Maps MCP Server

by arthurkatcher
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Google Maps MCP Server

PyPI version Python 3.10+ License: MIT MCP

gmaps-mcp is an MCP server that gives Claude Desktop, Cursor, and Claude Code full Google Maps capabilities — places search, place details, nearby search, directions, geocoding, and reverse geocoding. Install with one line (uvx gmaps-mcp), drop a config block into your MCP client, and your AI assistant can talk to Google Maps natively.

Built on the official Model Context Protocol Python SDK with FastMCP. Supports both stdio transport (local Claude Desktop / Cursor usage) and streamable HTTP transport (for remote deployments and A2A agent-to-agent scenarios).

What you can ask Claude once it's installed

  • "Find specialty coffee shops near me in San Francisco"

  • "What are the best ramen places in Shibuya, Tokyo, with reviews?"

  • "How long does it take to walk from Union Square to the Ferry Building?"

  • "Give me driving directions from SFO to Berkeley"

  • "What are the coordinates of the Eiffel Tower?"

  • "What's the address at 37.8199, -122.4783?"

  • "Find a 24-hour pharmacy within 2 km of these coordinates"

  • "Show me the top-rated Italian restaurants in North Beach with their hours and phone numbers"

The MCP client picks the right tool automatically — you don't name it.

Related MCP server: Google Maps MCP Server

Install in Claude Desktop

Edit your claude_desktop_config.json (Settings → Developer → Edit Config) and add:

{
  "mcpServers": {
    "google-maps": {
      "command": "uvx",
      "args": ["gmaps-mcp"],
      "env": {
        "GOOGLE_MAPS_API_KEY": "your_google_maps_api_key_here"
      }
    }
  }
}

Restart Claude Desktop. uvx fetches gmaps-mcp from PyPI on first run and caches it — no cloning, no venv, no Docker.

Install in Cursor

Edit ~/.cursor/mcp.json and add:

{
  "mcpServers": {
    "google-maps": {
      "command": "uvx",
      "args": ["gmaps-mcp"],
      "env": {
        "GOOGLE_MAPS_API_KEY": "your_google_maps_api_key_here"
      }
    }
  }
}

Restart Cursor. Done.

Install in Claude Code

One command from your terminal:

claude mcp add google-maps \
  -e GOOGLE_MAPS_API_KEY=your_google_maps_api_key_here \
  -- uvx gmaps-mcp

Confirm with claude mcp list.

Get a Google Maps API key

You need a Google Maps Platform API key with Places API (New), Directions API, and Geocoding API enabled. It takes 3 minutes. Google gives $200/month in free Maps credit, far more than solo or small-team use will ever consume.

Step-by-step

  1. Go to Google Cloud Console and create (or pick) a project.

  2. Enable billing on the project. This is required even for the free tier. If you skip this step, every Google Maps call will return 403 BILLING_DISABLED (see Troubleshooting). Add a card — the free credit runs first, so you will not be charged for normal use.

  3. Enable these APIs in APIs & Services → Library:

    • Places API (New) — powers search_places, get_place_details, search_nearby

    • Directions API — powers get_directions

    • Geocoding API — powers geocode, reverse_geocode

  4. Go to APIs & Services → Credentials → + CREATE CREDENTIALS → API key.

  5. (Recommended) Click the new key → Edit → API restrictions → restrict to just those three APIs.

  6. Copy the key into your MCP client config above.

Tools

All six tools are real Google Maps calls against live data. No mocks, no stub responses.

Tool

What it does

search_places

Text search for businesses, landmarks, POIs

get_place_details

Reviews, amenities, hours, phone, price level for a specific place

search_nearby

Find places within a radius of GPS coordinates, filtered by type

get_directions

Step-by-step routes — driving, walking, bicycling, transit

geocode

Address or landmark → GPS coordinates

reverse_geocode

GPS coordinates → human-readable address

search_places

Text search for places by natural-language query. Returns businesses, landmarks, and points of interest with ratings, addresses, phone numbers, websites, opening hours, and coordinates.

Ask Claude:

  • "find specialty coffee shops in San Francisco"

  • "best ramen in Shibuya"

  • "24-hour pharmacies in Brooklyn"

  • "pet-friendly cafes near Golden Gate Park"

Returns: query, total_results, places[] with name, address, phone, website, google_maps_url, rating, reviews_count, price_level, types, latitude, longitude, is_open_now, opening_hours, business_status.

get_place_details

Get rich details about a specific place using its Google Place ID (returned by search_places). Includes reviews, amenities, editorial summary, and payment options.

Ask Claude:

  • "show me the reviews for that first coffee shop"

  • "is the second restaurant dog-friendly? do they have outdoor seating?"

  • "what are the opening hours and phone number of the place I just asked about"

Returns: everything from search_places plus top 5 reviews (author, rating, text, relative time), editorial_summary, and amenity flags: delivery, dine_in, takeout, reservable, outdoor_seating, live_music, payment_options, accessibility_options.

search_nearby

Find places within a radius of specific GPS coordinates. Use after geocode gives you a location, or when the user provides coordinates directly.

Ask Claude:

  • "find cafes within 500 meters of these coordinates"

  • "what hotels are within 2 km of the Eiffel Tower?"

  • "show me gas stations within 5 km of 37.7955, -122.3937"

Parameters: latitude, longitude, radius_meters (max 50,000), place_type (optional — restaurant, cafe, bar, hotel, gas_station, pharmacy, hospital, etc.), max_results.

Returns: center, radius_meters, place_type, total_results, places[] with the same fields as search_places.

get_directions

Step-by-step navigation between two locations, with total distance and duration. Supports driving (with traffic-aware duration), walking, bicycling, and public transit.

Ask Claude:

  • "how do I walk from Union Square to the Ferry Building?"

  • "give me driving directions from SFO to Berkeley with traffic"

  • "bicycle route from Central Park to Times Square"

Parameters: origin (address, landmark, or "lat,lng"), destination (same), mode ("driving" default, "walking", "bicycling", "transit").

Returns: origin, destination, mode, routes[] with summary, legs[] containing start_address, end_address, distance, duration, duration_in_traffic, and steps[] with step-by-step instruction, distance, duration.

geocode

Convert an address, landmark, or place description into GPS coordinates.

Ask Claude:

  • "what are the coordinates of the Eiffel Tower?"

  • "geocode 1600 Amphitheatre Parkway, Mountain View"

  • "find the latitude and longitude of Ferry Building San Francisco"

Returns: query, formatted_address, latitude, longitude, place_id, location_type, types.

reverse_geocode

Convert GPS coordinates into a human-readable address.

Ask Claude:

  • "what's at 37.8199, -122.4783?"

  • "reverse geocode these coordinates: 48.8584, 2.2945"

  • "what address is at latitude 40.7580, longitude -73.9855?"

Returns: latitude, longitude, formatted_address, place_id, address_components[].

Troubleshooting

403 BILLING_DISABLED / 403 Forbidden from Google

This is the most common setup issue. The error looks like:

Google Maps API error: 403 - {
  "error": {
    "code": 403,
    "message": "This API method requires billing to be enabled...",
    "status": "PERMISSION_DENIED",
    "details": [{"reason": "BILLING_DISABLED", ...}]
  }
}

Fix: Go back to step 2 of the API key setup and enable billing on your GCP project. Billing is required even though you will never actually be charged for normal solo use (Google's $200/month free credit handles it). Wait 2-3 minutes after enabling for the change to propagate through Google's systems, then retry.

API_KEY_INVALID / API project not authorized

You enabled billing but forgot to enable the specific APIs. Go back to step 3 and turn on Places API (New), Directions API, and Geocoding API individually.

uvx: command not found

Install uv first: curl -LsSf https://astral.sh/uv/install.sh | sh (macOS/Linux) or powershell -c "irm https://astral.sh/uv/install.ps1 | iex" (Windows).

Tools work in HTTP mode but not stdio (or vice versa)

Both transports share the exact same client and tool implementations — if one works, the other should too. If you hit a mismatch, open an issue with the error output.

Why this MCP server

If you're searching PyPI for a Google Maps MCP server, you'll find a couple of options. Here's what's different about gmaps-mcp:

  • Both transports in one package. Stdio for Claude Desktop / Cursor / Claude Code local usage, streamable HTTP for remote deployment and A2A scenarios. Same codebase, same tools, same behavior.

  • All six Google Maps capabilities. Not just search — places details, nearby search, directions with traffic, geocoding, reverse geocoding.

  • Uses Places API (New). The current Google Places API, not the legacy v1 endpoints that Google has deprecated.

  • Real FastMCP implementation. Built on the official MCP Python SDK, not a hand-rolled protocol parser.

  • MIT licensed, zero telemetry. Your queries never leave your machine except to hit Google's APIs directly.

  • Tested against the real API. Every tool is verified end-to-end against live Google endpoints on both transports.

Remote HTTP server mode

For deployments, shared team usage, or A2A agent-to-agent scenarios, gmaps-mcp also runs as a streamable HTTP server with optional API key auth.

git clone https://github.com/arthurkatcher/google-maps-mcp
cd google-maps-mcp
uv sync
cp .env.example .env  # edit with your API key
python run.py

Server listens on http://127.0.0.1:8000 by default, MCP endpoint at /mcp/, health check at /health. For local-only use you can leave MCP_API_KEY unset.

⚠️ Before exposing the server publicly (ngrok, reverse proxy, LAN, etc.): set MCP_API_KEY to a random secret. Without it, anyone who reaches the URL can run searches against your billed GOOGLE_MAPS_API_KEY. Also bind to 127.0.0.1 and let your tunnel/proxy forward from there, rather than binding 0.0.0.0 directly.

# .env
MCP_API_KEY=$(openssl rand -hex 32)
MCP_HOST=127.0.0.1

# then
python run.py
ngrok http 8000 --host-header=rewrite
# clients call https://your-ngrok-url.ngrok-free.dev/mcp/ with X-API-Key: <secret>

ℹ️ Why --host-header=rewrite. The MCP Python SDK's HTTP transport validates the Host header to block DNS-rebinding attacks against localhost servers. ngrok's default forwards the public hostname, which the SDK rejects with 421 Invalid Host header. --host-header=rewrite makes ngrok forward the upstream Host (127.0.0.1:8000), which passes the check. The same reasoning applies to other tunnels and reverse proxies — set the upstream Host to your bind address.

Security considerations

When you run gmaps-mcp over HTTP, treat MCP_API_KEY as a credential that gates a billed Google Cloud account. A few operator-side defaults worth having in place:

  • Rotate the key on suspected exposure. It's a single env var; pasting it in a screenshot, committed log, or shared session is enough to leak it.

  • Set a Google Cloud billing alert on the GCP project that holds your GOOGLE_MAPS_API_KEY. Pick a threshold that's well under whatever number would ruin your week. This is the cheap backstop against any leak — your key, the MCP key, or a third-party scraping the tunnel URL.

  • Restrict the Google Maps API key to just the three APIs gmaps-mcp uses (Places API New, Directions, Geocoding) under APIs & Services → Credentials → Edit. Optionally pin it to your home/server IP for defense in depth.

  • No server-side rate limiting yet. A leaked MCP_API_KEY lets an attacker burn quota as fast as their bandwidth allows. Until that lands, the billing alert is your circuit breaker.

  • Don't expose MCP_HOST=0.0.0.0 without a key. If you do, the server refuses to start (this is enforced in 0.1.3+ — a deliberate guardrail added after GHSA-52cq-7v8r-62c6).

Pricing

Google's Maps Platform offers a $200/month free credit that covers roughly:

  • ~11,000 Places API (New) requests, or

  • ~40,000 Geocoding API requests, or

  • ~40,000 Directions API requests.

For solo or small-team use, you will almost never hit the cap. Past the free tier, expect approximately $17 per 1,000 Places requests and $5 per 1,000 Geocoding/Directions requests. See Google Maps Platform pricing for current rates.

Development

git clone https://github.com/arthurkatcher/google-maps-mcp
cd google-maps-mcp
uv sync
cp .env.example .env  # add your real API key

# Run in stdio mode (for local MCP clients)
uv run python -m google_maps_mcp

# Run in HTTP mode (for remote clients)
uv run python run.py

Roadmap

  • Places API v2 fields — exploiting newer review/media fields as Google rolls them out

  • Traffic-aware ETA tool — dedicated tool for real-time travel time with traffic

  • Place photos — tool to fetch PlacePhoto URLs for UI rendering

  • Static maps rendering — optional tool to return a static map image for a place or route

  • Autocomplete suggestions — for building typeahead UX on top of the MCP server

  • MCP registry submission — listing on registry.modelcontextprotocol.io once it stabilizes

Project structure

google-maps-mcp/
├── pyproject.toml
├── README.md
├── LICENSE
├── run.py                    # HTTP server entry point
└── src/google_maps_mcp/
    ├── __init__.py
    ├── __main__.py           # stdio server entry point
    ├── client.py             # Google Maps API client
    ├── tools.py              # Tool wrappers
    └── server.py             # FastMCP server + Starlette HTTP middleware

License

MIT — see LICENSE. Use it anywhere, fork it, ship it.

Credits

Built by Arthur Katcher. Contributions, bug reports, and PRs welcome at github.com/arthurkatcher/google-maps-mcp.

If this MCP server saves you time, a GitHub star is the only payment I ask for.

Available Tools

6 tools
geocodeA

Convert an address or place description to GPS coordinates.

Use this when a user describes their location (hotel name, landmark, street address) and you need coordinates for search_nearby.

Args: address: Address, place name, landmark, or location description. Examples: "Ferry Building San Francisco", "Eiffel Tower Paris", "Times Square New York"

Returns: Dictionary with: - formatted_address: The official address Google matched - latitude: Latitude coordinate - longitude: Longitude coordinate
- place_id: Google Place ID

Example: geocode("Ferry Building, San Francisco")

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYes

TDQS

A4.8/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses the input format, return structure (formatted_address, latitude, longitude, place_id), and provides an example. It does not mention error handling, rate limits, or accuracy, but for a simple geocoding tool the information is sufficient.

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 front-loaded with the purpose, followed by usage guidance, then structured Args/Returns/Example. Every sentence adds value, with no redundancy. It is concise yet complete.

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

Completeness5/5

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

Given the tool has only one parameter and no output schema, the description fully covers input semantics, return structure, and example usage. It is complete for an agent to select and invoke the tool correctly.

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

Parameters5/5

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

Schema coverage is 0%, so description must compensate. It explains the address parameter can be 'Address, place name, landmark, or location description' and gives concrete examples like 'Ferry Building San Francisco'. This adds significant meaning beyond the schema's type string.

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 'Convert an address or place description to GPS coordinates' which is a specific verb+resource. It clearly distinguishes from sibling tools like get_directions, reverse_geocode, and search_nearby that have different purposes.

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 explicitly says 'Use this when a user describes their location... and you need coordinates for search_nearby.' This provides clear context for when to use this tool over alternatives, directly naming a sibling tool as a downstream use case.

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

get_directionsA

Get directions and route between two locations.

Returns step-by-step directions with distance and duration. Note: Requires Directions API to be enabled in Google Cloud.

Args: origin: Starting point - can be address or "lat,lng" coordinates destination: End point - can be address or "lat,lng" coordinates
mode: Travel mode - "driving" (default), "walking", "bicycling", or "transit"

Returns: Dictionary with route information including: - Total distance and duration - Step-by-step navigation instructions - Traffic duration (for driving) - Route warnings

Example: get_directions("Union Square, San Francisco", "Ferry Building, San Francisco", mode="walking")

ParametersJSON Schema
NameRequiredDescriptionDefault
originYes
destinationYes
modeNodriving

TDQS

A4.5/5.0
Behavior4/5

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

No annotations provided, but the description details the return format (dictionary with distance, duration, steps, traffic duration, warnings) and mentions the API requirement. It does not cover rate limits or errors but is fairly transparent.

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 concise and well-structured with Args, Returns, and Example sections. Every sentence adds value without redundancy.

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 3 parameters, no output schema, and no annotations, the description covers inputs, outputs, and an example. It does not mention error handling or limitations, but is adequate for this complexity.

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

Parameters5/5

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

Schema description coverage is 0%, but the description explains each parameter: origin/destination can be address or coordinates, mode has default and options. This provides full semantic meaning beyond the schema.

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 it 'Get directions and route between two locations' and mentions step-by-step directions, which distinguishes it from sibling tools like geocode or search_places.

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 explains when to use (get directions), includes a note about enabling the Directions API, and provides an example. It lacks explicit alternatives or when-not-to-use guidance, but context is clear.

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

get_place_detailsA

Get detailed information about a specific place by its Google Place ID.

Use this to get more details about a place after finding it with search_places. Returns additional info like reviews, amenities, and editorial summaries.

Args: place_id: Google Place ID (e.g., "places/ChIJN1t_tDeuEmsRUsoyG83frY4")

Returns: Dictionary with detailed place information including: - Basic info: name, address, phone, website, rating - Reviews: Top 5 user reviews with ratings and text - Amenities: delivery, dine_in, takeout, outdoor_seating, etc. - Opening hours and business status

ParametersJSON Schema
NameRequiredDescriptionDefault
place_idYes

TDQS

A4.4/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It describes what is returned (reviews, amenities, etc.) but does not disclose any behavioral traits such as read-only nature, required permissions, rate limits, or error conditions. The description is not misleading but incomplete for a no-annotation scenario.

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?

Well-structured with a clear purpose statement followed by usage hint and a detailed Args/Returns breakdown. Every sentence adds value; no fluff. Front-loaded with the main action, making it efficient for an agent to parse.

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

Completeness5/5

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

Despite no output schema, the description thoroughly enumerates return fields (basic info, top reviews, amenities, opening hours). Parameter coverage is complete with example. The tool is simple (1 param), and the description leaves no significant gaps for an agent to correctly invoke and interpret the result.

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

Parameters5/5

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

Schema has 0% description coverage (no parameter description for place_id), but the description provides the meaning: 'Google Place ID' with a concrete example. This fully compensates for the schema gap, adding critical context beyond the raw schema.

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?

Explicitly states it gets detailed information about a place by Google Place ID. Clearly differentiates from sibling 'search_places' by specifying 'after finding it with search_places' and lists specific additional info (reviews, amenities, editorial summaries). Verb+resource+scope is precise and distinct.

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?

Explicitly says 'Use this to get more details about a place after finding it with search_places', establishing a clear usage sequence. Does not explicitly mention when not to use or alternative tools like geocode/reverse_geocode, but the context is sufficient for correct selection.

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

reverse_geocodeA

Convert GPS coordinates to a human-readable address.

Use this when you have coordinates and need to know the address.

Args: latitude: Latitude coordinate (e.g., 42.4531) longitude: Longitude coordinate (e.g., 18.5375)

Returns: Dictionary with formatted address and location details.

Example: reverse_geocode(42.4531, 18.5375)

ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYes
longitudeYes

TDQS

A3.9/5.0
Behavior3/5

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

No annotations provided, so description must carry behavioral info. It specifies return value (dictionary with formatted address and details), but omits error handling, input validation, or performance traits. 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.

Conciseness5/5

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

Concise and well-structured: short description block followed by Args, Returns, and Example sections. No redundant sentences; every line provides useful information efficiently.

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 no output schema, the description appropriately explains the return value (dictionary with formatted address and location details). Could specify more detail about address components, but adequate for the tool's simplicity.

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 has 0% description coverage, so description must compensate. It adds explanation for latitude and longitude with example values (42.4531, 18.5375), clarifying usage beyond the raw schema. Good value add.

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 clearly states the action (convert GPS coordinates) and the result (human-readable address). It distinguishes from siblings like 'geocode' (likely address to coordinates) but does not explicitly differentiate from others.

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?

Directly tells when to use: 'Use this when you have coordinates and need to know the address.' It does not explicitly state when not to use or mention alternatives, but the guidance is clear and practical.

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

search_nearbyA

Search for places near specific coordinates.

Use this when you have GPS coordinates and want to find places nearby. Great for "find restaurants near me" type queries.

Args: latitude: Latitude of the center point (e.g., 42.4531) longitude: Longitude of the center point (e.g., 18.5375) radius_meters: Search radius in meters (default 1000, max 50000) place_type: Optional type filter like "restaurant", "cafe", "hotel", "gas_station", "pharmacy", "hospital", etc. max_results: Number of results to return (1-20). Default 10.

Returns: Dictionary with center point, radius, and list of nearby places.

Example: search_nearby(42.4531, 18.5375, radius_meters=500, place_type="cafe")

ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYes
longitudeYes
radius_metersNo
place_typeNo
max_resultsNo

TDQS

A4.6/5.0
Behavior4/5

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

Describes return format (dictionary with center point, radius, and place list) and parameter constraints (radius max 50000, max_results limit). No annotations exist, so disclosure is adequate for a read-only search; no side effects or auth requirements mentioned.

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?

Well-structured: brief intro sentence, usage guidance, labeled Args list, Returns, and Example. Every element earns its place; no fluff.

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

Completeness5/5

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

Given no output schema and no annotations, the description covers purpose, usage, all parameters (with details), return format, and an example. No obvious gaps for this tool's complexity.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by detailing each parameter: units for radius, example values for latitude/longitude, optional place_type with examples, and default values. Adds significant meaning beyond the schema.

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?

Explicitly states 'Search for places near specific coordinates' and gives a concrete example ('find restaurants near me'). It differentiates from siblings like 'search_places' (text-based) and 'geocode' (address to coordinates) by emphasizing GPS coordinate input.

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?

Clearly advises when to use: 'Use this when you have GPS coordinates and want to find places nearby.' Provides common query type. Lacks explicit exclusions or alternatives, but context implies it's for coordinate-based searches.

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

search_placesA

Search Google Maps for places based on a text query.

This tool searches for businesses, locations, and points of interest using Google Maps Places API. It returns detailed information including contact details, ratings, opening hours, and location data.

Args: query: Search query like "coffee in San Francisco" or "pizza restaurants in New York City". Can include location and business type. max_results: Number of results to return (1-20). Default is 10.

Returns: Dictionary containing query, total_results, and places list with detailed information including name, address, phone, website, rating, location, hours, and more.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
max_resultsNo

TDQS

A4.5/5.0
Behavior4/5

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

Describes the return data comprehensively (contact, ratings, hours) but lacks disclosure of rate limits or usage costs. No annotations exist, so description carries the burden.

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?

Well-structured with Args and Returns sections, but slightly verbose with repetitive opening sentences.

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

Completeness5/5

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

Given only 2 parameters and no output schema, the description fully explains inputs and outputs, making it complete for agent use.

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

Parameters5/5

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

With 0% schema coverage, the description adds significant meaning: explains query format with examples and clarifies max_results range and default.

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?

Clearly states the verb 'search' and resource 'Google Maps places' with a text query. Distinguishes from sibling tools like search_nearby (location-based) by emphasizing textual queries.

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?

Provides clear context for when to use (text-based searches) but does not explicitly mention when not to use or alternatives among siblings.

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.

  1. 6 tool updatesv0.1.4
    • First observedgeocode
    • First observedget_directions
    • First observedget_place_details
    • First observedreverse_geocode
    • First observedsearch_nearby
    • First observedsearch_places
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a distinct purpose: geocode and reverse_geocode handle coordinate conversion, search_places and search_nearby cover two search modes, get_directions provides routing, and get_place_details retrieves detailed info. No two tools overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_directions, search_nearby, reverse_geocode), making them predictable and easy to understand.

Tool Count5/5

With 6 tools, the server is well-scoped for a maps MCP, covering core geocoding, directions, and place search without being overly numerous or sparse.

Completeness4/5

The tool set covers essential geocoding, routing, and place search features. Minor gaps exist (e.g., no distance matrix or batch geocoding), but core map interactions are well supported.

Maintenance

ActivityInactive
ResponsivenessResponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/arthurkatcher/google-maps-mcp'

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