Provides tools for interacting with Google Maps Platform APIs, enabling location intelligence capabilities such as place search, directions, geocoding, traffic analysis, road data, and elevation calculations.
Click on "Install 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-server search for pizza places in Chicago"
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.
Production-ready Model Context Protocol (MCP) server for Google Maps Platform APIs.
Empower your AI agents with real-world location intelligence: directions, places, geocoding, traffic analysis, and road network data—all through a standardised MCP interface.
Production-Ready: Robust error handling, automatic retries with exponential backoff, structured logging
Universal Integration: Works with Claude Desktop, Google ADK, and any MCP-compatible client
Comprehensive API Coverage: 11 tools spanning all major Google Maps APIs
Type-Safe: Full type annotations with Pydantic validation and mypy compliance
Zero Configuration: Sensible defaults, works out of the box
Thoroughly Tested: >90% code coverage with unit and integration tests
Docker Support: Ready-to-deploy container images
Excellent Documentation: Extensive examples, API reference, and best practices
Modern Python: Built for Python 3.10+ using uv package manager
Related MCP server: OpenStreetMap MCP Server
API | Tool | Description | Use Cases |
Places API |
| Find points of interest near a location | Restaurant recommendations, gas station finder, POI search |
Places API |
| Get comprehensive details for a place | Opening hours, websites, phone numbers, accessibility info |
Directions API |
| Get routes with real-time traffic | Route planning, ETA calculation, alternative routes |
Directions API |
| Analyse real-time traffic congestion | Commute monitoring, delay estimation, fleet routing |
Geocoding API |
| Convert addresses to coordinates | Address validation, location lookup |
Geocoding API |
| Convert coordinates to addresses | Location identification, address lookup |
Distance Matrix API |
| Multi-origin/destination distances | Fleet routing, delivery optimisation, travel planning |
Roads API |
| Snap GPS points to road network | GPS trace cleaning, route reconstruction |
Roads API |
| Retrieve speed limit data | Fleet safety monitoring, compliance checking |
Elevation API |
| Calculate elevation gain and profile | Cycling/hiking planning, fuel efficiency |
Compound |
| Assess route safety risks | Fleet safety, insurance scoring, driver assistance |
Python 3.10 or higher (3.14+ recommended)
uv package manager (optional but recommended)
uv pip install google-maps-mcp-serverpip install google-maps-mcp-servergit clone https://github.com/ettysekhon/google-maps-mcp-server.git
cd google-maps-mcp-server
uv syncVisit the Google Cloud Console
Create a new project or select an existing one
Enable the following APIs:
Places API
Directions API
Geocoding API
Distance Matrix API
Roads API
Create credentials (API Key)
Restrict your API key (recommended):
Application restrictions: HTTP referrers or IP addresses
API restrictions: Select only the APIs listed above
Create a .env file in your working directory:
GOOGLE_MAPS_API_KEY=your_maps_api_key_here
LOG_LEVEL=INFO
MAX_RESULTS=20Or set environment variables:
export GOOGLE_MAPS_API_KEY="your_maps_api_key_here"# Using the installed command
google-maps-mcp-server
# Or using Python module
python -m google_maps_mcp_server
# Or using uv
uv run google-maps-mcp-serverSee DEPLOYMENT.md for full instructions, troubleshooting, and architecture details.
# Set your API key (or create a .env file)
export GOOGLE_MAPS_API_KEY=your-key
# Build and run
make docker-run
# Verify (in another terminal)
make verify-local# Set environment
export GOOGLE_CLOUD_PROJECT=your-project-id
export GOOGLE_CLOUD_REGION=europe-west2
# First time: create secret
make deploy-secret
# Deploy (build, push, apply)
make deploy-all
# Check status
make deploy-status# Rebuild and push new image
make deploy-build
# Force pod to pull new image
kubectl delete pod -l app=google-maps-mcp-server
# Watch for new pod to be ready
kubectl get pods -l app=google-maps-mcp-server -wVerify your deployment using the official MCP Inspector:
npx @modelcontextprotocol/inspectorTransport Type: SSE
URL: http://<EXTERNAL-IP>/sse (or http://localhost:8080/sse for local)
Should see 11 tools listed
Run make help to see all available commands.
Add to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"google-maps": {
"command": "uvx",
"args": ["google-maps-mcp-server"],
"env": {
"GOOGLE_MAPS_API_KEY": "your_api_key_here"
}
}
}
}Or if installed globally:
{
"mcpServers": {
"google-maps": {
"command": "google-maps-mcp-server",
"env": {
"GOOGLE_MAPS_API_KEY": "your_api_key_here"
}
}
}
}Now you can ask Claude:
"Find the best coffee shops near The Strand, London"
"What are the opening hours for the Natural History Museum?"
"How is the traffic from London to Manchester right now?"
"Is the route from Edinburgh to Glasgow safe for night driving?"
"Convert the address '10 Downing Street, London' to coordinates"
"What's the address for coordinates 51.5074, -0.1278?"
"Find petrol stations within 2km of my current location at 51.5074,-0.1278"
from google.adk.agents import Agent
from google.adk.tools.mcp_tool import MCPToolset
from mcp.client.stdio import StdioServerParameters
async def create_location_agent():
# Connect to Google Maps MCP server
maps_tools = await MCPToolset.from_server(
connection_params=StdioServerParameters(
command='google-maps-mcp-server',
env={"GOOGLE_MAPS_API_KEY": "your_api_key_here"}
)
)
# Create agent with Maps tools
agent = Agent(
name="location_intelligence_agent",
model="gemini-2.0-flash",
instruction="""You are a location intelligence assistant with access to
Google Maps data. Help users with directions, place searches, and location queries.""",
tools=[maps_tools]
)
return agent
# Use the agent
agent = await create_location_agent()
response = await agent.run("Find Italian restaurants near Hyde Park, London")
print(response)import asyncio
from google_maps_mcp_server import GoogleMapsMCPServer, Settings
async def main():
# Initialise with custom settings
settings = Settings(
google_maps_api_key="your_api_key_here",
log_level="DEBUG",
max_results=10
)
server = GoogleMapsMCPServer(settings)
# Run the server
await server.run()
if __name__ == "__main__":
asyncio.run(main())from google_maps_mcp_server.tools import PlacesTool, DirectionsTool
from google_maps_mcp_server.config import Settings
async def find_nearby_restaurants():
settings = Settings(google_maps_api_key="your_key")
places_tool = PlacesTool(settings)
result = await places_tool.execute({
"location": "51.5118,-0.1175", # The Strand, London
"keyword": "pizza",
"radius": 1000
})
print(f"Found {result['data']['count']} pizza places")
for place in result['data']['places']:
print(f"- {place['name']}: {place['rating']}⭐")
asyncio.run(find_nearby_restaurants())# Build the image
docker build -t google-maps-mcp .
# Run the container
docker run -it \
-e GOOGLE_MAPS_API_KEY=your_maps_key_here \
google-maps-mcp
# Or use docker-compose
docker-compose upAll configuration can be set via environment variables or .env file:
Variable | Type | Default | Description |
| string | required | Google Maps Platform API key (for Maps tools) |
| string |
| Logging level (DEBUG, INFO, WARNING, ERROR, CRITICAL) |
| integer |
| Maximum results to return (1-60) |
| integer |
| Default search radius in meters |
| integer |
| Maximum allowed search radius |
| integer |
| Maximum retry attempts for failed requests |
| float |
| Minimum wait between retries (seconds) |
| float |
| Maximum wait between retries (seconds) |
search_placesFind places near a location.
Parameters:
location (required): Coordinates as "lat,lng" or address string
keyword (required): Search keyword (e.g., "restaurant", "petrol station")
radius (optional): Search radius in meters (default: 5000, max: 50000)
type (optional): Place type filter (e.g., "restaurant", "gas_station")
Example:
{
"location": "51.5118,-0.1175",
"keyword": "coffee shop",
"radius": 1000,
"type": "cafe"
}get_place_detailsGet detailed information about a specific place.
Parameters:
place_id (required): The unique Place ID
fields (optional): Specific fields to retrieve (e.g., ["name", "phone", "hours"])
Example:
{
"place_id": "ChIJN1t_tDeuEmsRUsoyG83frY4",
"fields": ["name", "website", "hours"]
}get_directionsGet route directions with real-time traffic.
Parameters:
origin (required): Start location (address or coordinates)
destination (required): End location (address or coordinates)
mode (optional): Travel mode - "driving" (default), "walking", "bicycling", "transit"
departure_time (optional): ISO 8601 timestamp for traffic estimation
alternatives (optional): Return alternative routes (default: true)
avoid (optional): Features to avoid - ["tolls", "highways", "ferries", "indoor"]
traffic_model (optional): "best_guess" (default), "optimistic", "pessimistic"
Example:
{
"origin": "London, UK",
"destination": "Manchester, UK",
"mode": "driving",
"alternatives": true,
"avoid": ["tolls"]
}get_traffic_conditionsAnalyze real-time traffic conditions between two locations.
Parameters:
origin (required): Starting location
destination (required): Ending location
departure_time (optional): ISO 8601 timestamp (defaults to now)
traffic_model (optional): "best_guess" (default), "optimistic", "pessimistic"
Example:
{
"origin": "London, UK",
"destination": "Oxford, UK",
"traffic_model": "best_guess"
}geocode_addressConvert an address to coordinates.
Parameters:
address (required): Street address to geocode
components (optional): Component filters (e.g., {"country": "GB"})
region (optional): Region bias (ISO 3166-1 country code)
Example:
{
"address": "10 Downing Street, London, UK"
}reverse_geocodeConvert coordinates to an address.
Parameters:
lat (required): Latitude (-90 to 90)
lng (required): Longitude (-180 to 180)
result_type (optional): Filter by result types
Example:
{
"lat": 51.5034,
"lng": -0.1276
}calculate_distance_matrixCalculate distances and times between multiple locations.
Parameters:
origins (required): Array of origin locations
destinations (required): Array of destination locations
mode (optional): Travel mode (default: "driving")
avoid (optional): Features to avoid
units (optional): "metric" (default) or "imperial"
Example:
{
"origins": ["London, UK", "Manchester, UK"],
"destinations": ["Birmingham, UK", "Leeds, UK"],
"mode": "driving"
}snap_to_roadsSnap GPS coordinates to the nearest road.
Parameters:
path (required): Array of GPS points with lat/lng (2-100 points)
interpolate (optional): Fill gaps between points (default: true)
Example:
{
"path": [
{"lat": 51.5034, "lng": -0.1276},
{"lat": 51.5035, "lng": -0.1275}
],
"interpolate": true
}get_speed_limitsGet speed limit data for road segments.
Parameters:
place_ids (required): Array of place IDs from snap_to_roads
Example:
{
"place_ids": ["ChIJwQ2rKwAEdkgRo7h2RYD1oUM"]
}calculate_route_safety_factorsCalculate safety scores for a route based on traffic, road conditions, and speed limits.
Parameters:
origin (required): Starting location
destination (required): Ending location
departure_time (optional): ISO 8601 timestamp (defaults to now)
traffic_model (optional): "best_guess", "optimistic", "pessimistic" (default)
Example:
{
"origin": "London, UK",
"destination": "Oxford, UK",
"departure_time": "2023-10-27T23:00:00Z",
"traffic_model": "pessimistic"
}get_route_elevation_gainCalculate elevation gain and retrieve elevation profile for a route.
Parameters:
origin (required): Starting location
destination (required): Ending location
mode (optional): "driving", "walking", "bicycling" (default)
samples (optional): Number of elevation samples (default: 50, max: 512)
Example:
{
"origin": "London, UK",
"destination": "Brighton, UK",
"mode": "bicycling",
"samples": 100
}# Clone the repository
git clone https://github.com/ettysekhon/google-maps-mcp-server.git
cd google-maps-mcp-server
# Install uv if you haven't already
curl -LsSf https://astral.sh/uv/install.sh | sh
# Install dependencies with dev extras
uv sync --extra dev
# Set up pre-commit hooks
uv run pre-commit install# Run all tests
uv run pytest
# Run with coverage
uv run pytest --cov=src --cov-report=html
# Run only unit tests
uv run pytest -m "not integration"
# Run specific test file
uv run pytest tests/unit/test_places.py
# Run with verbose output
uv run pytest -v# Format code
uv run black src tests
# Lint code
uv run ruff check src tests
# Fix linting issues automatically
uv run ruff check src tests --fix
# Type checking
uv run mypy src
# Run all checks
uv run black src tests && \
uv run ruff check src tests && \
uv run mypy src && \
uv run pytest# Build package
uv build
# Publish to PyPI (requires authentication)
uv publish
# Build Docker image
docker build -t google-maps-mcp-server:latest .We welcome contributions! Please see CONTRIBUTING.md for guidelines.
Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Make your changes
Add tests for your changes
Ensure all tests pass (uv run pytest)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
This MCP server uses Google Maps Platform APIs which have the following considerations:
Free Tier: $200 monthly credit (covers ~28,000 geocoding requests or ~40,000 directions requests)
Pay-as-you-go: Pricing varies by API
Rate Limits: Default quotas apply; can be increased via Google Cloud Console
Cost Optimisation Tips:
Cache results when appropriate
Use alternatives=false for directions when not needed
Limit max_results for place searches
Implement client-side caching for repeated queries
See Google Maps Platform Pricing for details.
API Key Security:
Never commit API keys to version control
Use environment variables or secret management
Restrict API keys by API, HTTP referrer, or IP address
Rotate keys regularly
API Key Restrictions (Recommended):
Application restrictions: HTTP referrers or IP addresses
API restrictions:
- Places API
- Directions API
- Geocoding API
- Distance Matrix API
- Roads APIMonitoring:
Enable billing alerts in Google Cloud Console
Monitor API usage regularly
Set up quota alerts
Problem: ValidationError: google_maps_api_key cannot be empty
Solution: Ensure GOOGLE_MAPS_API_KEY environment variable is set
Problem: REQUEST_DENIED error
Solution: Enable required APIs in Google Cloud Console and check API key restrictions
Problem: OVER_QUERY_LIMIT error
Solution: You've exceeded API quota. Check usage in Google Cloud Console or implement rate limiting
Problem: Server won't start
Solution: Check logs for errors, verify Python version (3.10+), ensure all dependencies installed
export LOG_LEVEL=DEBUG
google-maps-mcp-serverThis project is licensed under the Apache License 2.0 - see the LICENSE file for details.
Built with MCP by Anthropic
Powered by Google Maps Platform
Developed using uv by Astral
Inspired by the amazing MCP community
Calculate travel distances and times between multiple origins and destinations. Useful for route optimization and fleet management.
| Name | Required | Description | Default |
|---|---|---|---|
| origins | Yes | List of origin locations (addresses or 'lat,lng') | |
| destinations | Yes | List of destination locations (addresses or 'lat,lng') | |
| mode | No | Travel mode | driving |
| avoid | No | Features to avoid | |
| units | No | Unit system for distances | metric |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states the basic functionality without disclosing details like output format (e.g., matrix), rate limits, or performance characteristics.
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 concise with two sentences, no wasted words, and front-loads the primary action.
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 no output schema, the description should explain return values (e.g., a distance matrix) but does not. Also lacks information on usage limits or prerequisites.
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% with parameter descriptions, so the description adds limited value beyond schema. It restates that origins and destinations are multiple, but does not clarify parameter usage nuances.
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 states the tool calculates travel distances and times between multiple origins and destinations, which distinguishes it from sibling tools like get_directions (for single routes) and geocode_address.
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 mentions usefulness for route optimization and fleet management, providing context, but does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate safety assessment for a route. Analyzes traffic congestion, road types, and speed limits to identify risk factors.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Starting location | |
| destination | Yes | Ending location | |
| departure_time | No | ISO 8601 timestamp for departure (defaults to now) | |
| traffic_model | No | Traffic prediction model (defaults to pessimistic for safety analysis) | pessimistic |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions analyzing factors but does not disclose output format, side effects, data freshness, or error conditions. Moderate transparency but lacks detail.
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?
Two concise sentences with no wasted words. Purpose stated first, followed by details. Efficient and easy to parse.
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?
Tool has 4 parameters and no output schema. Description fails to explain what the output is (risk score? categories? summary?), leaving the agent uncertain about return format. Incomplete for a tool with no output schema.
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 baseline 3. Description adds minimal extra meaning beyond schema; it mentions analyzed factors but does not connect them to parameters like origin/destination or traffic_model. The default pessimistic model for safety is useful context.
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?
Description clearly states the tool calculates a safety assessment for a route, analyzing traffic congestion, road types, and speed limits. This verb+resource specificity distinguishes it from siblings like get_directions or get_traffic_conditions.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for safety analysis but does not mention alternatives or exclusions, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a street address to geographic coordinates (latitude/longitude).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Street address to geocode | |
| components | No | Component filters (e.g., {'country': 'US'}) | |
| region | No | Region bias (ISO 3166-1 country code) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral traits. It does not mention what happens on failure, whether multiple results are returned, or any necessary authorization. The schema includes parameters like 'components' and 'region' but their behavioral impact is not explained.
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?
Single sentence is front-loaded and contains no redundant information. Every word earns its place. Highly concise.
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?
No output schema is provided, so the description should hint at return format. It only says 'latitude/longitude' without specifying whether it returns a single point, a list, or additional metadata. For a geocoding tool with 3 parameters (one nested), this is insufficiently 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 schema descriptions already document each parameter. The tool description adds no additional meaning beyond the schema, e.g., it merely restates 'address', 'components', and 'region' without elaborating on format constraints or usage nuances.
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 states the action ('Convert a street address to geographic coordinates') and the resource ('street address'). It is specific and distinguishes from siblings like 'reverse_geocode' which does the opposite.
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?
No guidance on when to use this tool versus alternatives such as 'get_place_details' or 'search_places'. No mention of context, prerequisites, or exclusions. The description implies usage but does not help an agent decide between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get route directions between origin and destination with real-time traffic data. Returns routes with distance, duration, steps, and traffic information.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Starting location (address or 'lat,lng') | |
| destination | Yes | Ending location (address or 'lat,lng') | |
| mode | No | Travel mode | driving |
| departure_time | No | ISO 8601 timestamp for departure (for traffic estimation) | |
| alternatives | No | Return alternative routes | |
| avoid | No | Features to avoid | |
| traffic_model | No | Traffic prediction model | best_guess |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions real-time traffic and returned fields (distance, duration, steps, traffic info). Lacks details on potential errors, max routes, or authorization needs.
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?
Single sentence, no wasted words. Efficiently conveys purpose and output.
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?
Adequate for a 7-param tool with no output schema or annotations. Covers basic purpose and output, but omits behavior details like default mode, how alternatives work, and error handling.
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 baseline is 3. Description adds that real-time traffic is supported, which relates to departure_time and traffic_model, but doesn't add meaning beyond schema descriptions.
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?
Clearly states 'Get route directions between origin and destination with real-time traffic data.' Verb is specific, resource is route directions. Distinguishes from siblings like calculate_distance_matrix and get_traffic_conditions by emphasizing full directions with traffic.
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?
No explicit guidance on when to use vs siblings. The description implies use for full directions, but alternatives like get_traffic_conditions or calculate_distance_matrix are not mentioned. Agent must infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific place using its Place ID. Returns address, phone number, website, opening hours, and other details.
| Name | Required | Description | Default |
|---|---|---|---|
| place_id | Yes | The unique Place ID | |
| fields | No | Specific fields to retrieve (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses read-only nature and return types, but doesn't mention authentication, rate limits, or error handling. Contradiction not applicable.
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?
Single sentence, front-loaded with purpose. Could be restructured with bullets for readability, but current form is efficient.
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?
Adequate for a 2-param read tool with no output schema. Explains what it returns but lacks guidance on error scenarios or return format. No output schema to rely on.
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 has 100% description coverage for place_id and fields. Description adds no extra meaning or constraints beyond schema, e.g., valid field values or usage of fields parameter.
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?
Clearly states the tool gets detailed information about a specific place using its Place ID, listing return types (address, phone number, etc.). Distinguishes from sibling tools like search_places, which returns a list.
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?
Implies usage context: when you have a Place ID and need details. Does not explicitly state when not to use or provide alternatives, but context with sibling names suggests appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate elevation gain and retrieve elevation profile for a route. Useful for cycling, hiking, or fuel efficiency analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Starting location (address or 'lat,lng') | |
| destination | Yes | Ending location (address or 'lat,lng') | |
| mode | No | Travel mode (elevation is most relevant for bicycling/walking) | bicycling |
| samples | No | Number of elevation samples along the route (max 512) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states basic function without disclosing behavioral traits like data source, precision, rate limits, or behavior when route lacks elevation data. Incomplete for a calculation tool.
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?
Two concise sentences: first defines function, second gives use cases. No wasted words, immediately readable.
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?
Adequate for a simple tool, but lacks details on output format, error handling, and parameter effects. No output schema means description should clarify return values. Could be improved.
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. Description adds minimal value beyond schema, only generic use-case context. Does not enhance parameter understanding (e.g., sample impact or mode differences).
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?
Clearly states the tool calculates elevation gain and retrieves elevation profile for a route, with specific use cases (cycling, hiking, fuel efficiency). It uniquely addresses elevation among siblings like calculate_distance_matrix or get_directions.
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?
Provides implicit context by mentioning 'cycling, hiking, or fuel efficiency' but lacks explicit guidance on when to use this tool versus alternatives (e.g., for distance use calculate_distance_matrix). No exclusions or when-not-to-use mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get speed limit data for road segments. Requires place IDs from snap_to_roads. Critical for fleet safety and compliance monitoring.
| Name | Required | Description | Default |
|---|---|---|---|
| place_ids | Yes | Place IDs from snap_to_roads results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as rate limits, error conditions, data format (e.g., units of speed), or whether the tool is idempotent. The mention of 'critical for fleet safety' provides importance but no behavioral specifics.
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 efficient sentences: first states the core purpose and input requirement, second adds context. No redundant words or 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?
The description provides basic information but lacks details about return values (e.g., speed limit format, units, data structure) which would be helpful since there is no output schema. It is adequate for a simple tool but could be more complete for safety-critical use.
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% and already explains the parameter as 'Place IDs from snap_to_roads results'. The description adds 'from snap_to_roads' which is redundant with the schema. No additional semantic value beyond the schema, so baseline 3 is appropriate.
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 states 'Get speed limit data for road segments' with a specific verb and resource. It distinguishes from siblings by specifying the prerequisite input (place IDs from snap_to_roads), which is unique among the listed sibling tools.
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 explicitly states 'Requires place IDs from snap_to_roads', giving clear context on when to use this tool (after snap_to_roads). It does not explicitly mention when not to use or list alternatives, but the prerequisite guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze real-time traffic conditions between origin and destination. Returns duration in traffic, delay estimates, and congestion level.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Starting location (address or 'lat,lng') | |
| destination | Yes | Ending location (address or 'lat,lng') | |
| departure_time | No | ISO 8601 timestamp for departure (defaults to now) | |
| traffic_model | No | Traffic prediction model | best_guess |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. It mentions 'real-time' but does not specify data source, limitations, or prerequisites (e.g., API key, internet). Lacks depth about what 'delay estimates' entail.
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?
Two sentences, front-loaded with purpose. 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?
No output schema; description lists return fields (duration, delay, congestion) but lacks structure or potential errors. Covers basic purpose but incomplete for a tool with 4 parameters and no annotations.
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 covers parameters fully (100% description coverage). Description adds no additional meaning beyond schema; it only names origin and destination but not specifics like format or defaults.
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 states the tool 'analyzes real-time traffic conditions' between origin and destination, specifying return values (duration, delay, congestion). Differentiates from siblings like 'get_directions' (route planning) and 'calculate_distance_matrix' (distances).
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?
No explicit guidance on when to use or not use this tool versus alternatives. Implies use for traffic-focused queries but does not mention exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert geographic coordinates (latitude/longitude) to a street address.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude | |
| lng | Yes | Longitude | |
| result_type | No | Filter by result types (e.g., ['street_address', 'route']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose behavioral traits like accuracy, coordinate system support, output format, or error handling. Minimal transparency.
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?
Single sentence, 8 words, front-loaded with the core action. No wasted words, perfectly concise.
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 no output schema, the description should explain the return value. It only says 'to a street address', leaving format unclear. Also lacks usage context among sibling tools, making it incomplete.
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?
The input schema has 100% description coverage, so baseline is 3. The description adds no extra meaning beyond the schema; it merely mentions coordinates and street address without elaborating on parameters.
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 states the tool converts geographic coordinates to a street address, using specific verbs and resources. This distinguishes it from sibling tools like geocode_address, which does the reverse.
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?
No guidance on when to use this tool versus alternatives, such as geocode_address or search_places. The description lacks context about prerequisites or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for nearby places based on location and keywords. Returns place names, addresses, ratings, and other details.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Location as 'lat,lng' (e.g., '37.7749,-122.4194') | |
| keyword | Yes | Keyword to search for (e.g., 'gas station', 'restaurant') | |
| radius | No | Search radius in meters (default: 5000, max: 50000) | |
| type | No | Place type (e.g., 'restaurant', 'gas_station', 'parking') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the tool searches and returns data, but omits details like authentication requirements, rate limits, error handling, or the fact that results may be limited. The description is sufficient for a simple search but lacks depth.
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 consists of two short sentences that convey the purpose and output without any fluff. Every word serves a purpose, making it highly concise and well-structured.
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 has no output schema, the description compensates by listing the types of data returned (names, addresses, ratings, etc.). However, it does not mention result limits, pagination, or how to interpret the 'other details'. Still, it provides sufficient context for a search tool.
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 minimal extra meaning beyond what the schema already provides (e.g., 'based on location and keywords' is a paraphrase). It does not explain how parameters interact or provide examples.
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 states the tool searches for nearby places based on location and keywords, and it lists the type of data returned. This distinguishes it from sibling tools like get_place_details (which retrieves details for a specific place) and geocode_address (which converts addresses to coordinates).
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 when to use (searching for places by location and keywords) but provides no explicit guidance on when not to use it or when to prefer a sibling tool like get_place_details or reverse_geocode. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Snap GPS coordinates to the nearest road. Useful for cleaning noisy GPS data from vehicle tracking systems.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Array of GPS coordinates to snap to roads | |
| interpolate | No | Fill gaps between GPS points |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the snapping action and use case, but does not mention whether the tool is read-only or destructive, authorization requirements, rate limits, or other side effects. The behavioral disclosure 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, highly concise, and front-loaded with the core purpose. Every sentence adds value with 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 (two parameters, no output schema), the description is adequate but incomplete. It provides purpose and a use case, but does not explain the output format, error conditions, or limitations beyond what is captured in the schema (e.g., min/max items). It is sufficient for basic understanding but could be more thorough.
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% (both 'path' and 'interpolate' have descriptions in the input schema). The tool description does not add substantial additional meaning beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('snap') and resource ('GPS coordinates to the nearest road'), clearly indicating the tool's function. It also provides a use case (cleaning noisy GPS data) which helps distinguish it from sibling tools like reverse_geocode or get_directions.
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 explicitly states the tool is useful for cleaning noisy GPS data from vehicle tracking systems, indicating a clear context for use. However, it does not provide explicit when-not-to-use guidance or mention alternative tools, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.1calculate_distance_matrixcalculate_route_safety_factorsgeocode_addressget_directionsget_place_detailsget_route_elevation_gainget_speed_limitsget_traffic_conditionsreverse_geocodesearch_placessnap_to_roadsEach tool has a clearly distinct purpose, from geocoding to directions to safety analysis. No two tools overlap in functionality; even geocode and reverse_geocode are complementary opposites.
All tool names follow a consistent verb_noun pattern in snake_case, with verbs like 'calculate', 'get', 'geocode', 'reverse_geocode', 'search', and 'snap'. The naming is predictable and aids agent selection.
With 11 tools covering geocoding, directions, places, traffic, roads, elevation, and safety, the set is well-scoped for Google Maps API capabilities. No unnecessary tools and no obvious missing core operations.
The tool set covers major Google Maps features (geocoding, directions, places, traffic, roads, elevation, distance matrix, safety). Minor gaps exist (e.g., place photos, time zone), but the surface is complete for most common use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Google Maps MCP server is a fully-managed server provided by the Maps Grounding Lite API that connects AI applications to Google Maps Platform services. It provides three main tools for building LLM applications: searching for places, looking up weather information, and computing routes with details like distance and travel time. The server acts as a proxy that translates Google Maps data into a format that AI applications can understand, enabling agents to accurately answer real-world location and travel queries.
Live Google Maps business search, review, and photo data for AI agents over MCP.
Hosted MCP with 91 agent tools: X, domains, SEO, Maps, Trends, Search, YouTube, TikTok, and more.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ettysekhon/google-maps-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
