Provides tools for using Google Maps Platform APIs, including place search and details, geocoding, turn-by-turn directions, distance matrices, elevation, and time zone lookups.
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 Get turn-by-turn directions from Portland to Seattle"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Google Maps Platform MCP server — places, geocoding, turn-by-turn directions, route matrices, elevation and time zones.
Built on the current Google APIs: Places API (New), Routes API v2, Geocoding API, Elevation API and Time Zone API. Turn-by-turn steps, transit routes and live traffic are included, which the Maps Grounding Lite MCP service does not provide.
npx -y @aiwerk/mcp-server-google-mapsOr add to your MCP client config:
{
"mcpServers": {
"google-maps": {
"command": "npx",
"args": ["-y", "@aiwerk/mcp-server-google-maps"],
"env": {
"GOOGLE_MAPS_API_KEY": "your-api-key"
}
}
}
}Related MCP server: Google Maps MCP Server
Variable | Required | Description |
| yes | API key from Google Cloud Console |
| no | Request timeout in ms (default: 30000) |
Each tool group calls a different API, and a disabled API answers REQUEST_DENIED or HTTP 403. Enable the ones you plan to use:
API | Powers |
Places API (New) |
|
Geocoding API |
|
Routes API |
|
Elevation API |
|
Time Zone API |
|
Billing must be enabled on the project. The legacy Places API and Directions API are not used, so enabling those alone is not enough.
11 read-only tools. Nothing in this server writes, and every tool is annotated readOnlyHint.
Name | Description |
| Text search for places, with optional area bias, type, rating, price and open-now filters. |
| Places inside a circle around a coordinate, with the radius as a hard restriction. |
| Full detail for one place ID: hours, phone, website, rating, optionally reviews. |
| Place suggestions plus place IDs for partially typed input. |
| Address to coordinates, with normalised address components and place ID. |
| Coordinates to the addresses at that point. |
| Place ID to address and coordinates through the cheaper Geocoding API. |
| Route with turn-by-turn steps, waypoints, traffic, alternatives and transit support. |
| Travel time and distance for every origin-destination pair. |
| Elevation for up to 100 points, or a sampled profile along a path. |
| Time zone, UTC offset and DST offset for a coordinate at a given moment. |
maps_directions and maps_distance_matrix accept three shapes for every location:
Shape | Example |
Address |
|
Coordinates |
|
Place ID |
|
maps_reverse_geocode, maps_elevation and maps_timezone need coordinates, since those APIs do not geocode. Run maps_geocode first.
Places and Routes calls are billed by the fields they request, so the field masks in this server are deliberately narrow.
maps_place_details leaves reviews out until you set include_reviews: true, which moves the call to the Enterprise + Atmosphere tier.
maps_directions requests turn-by-turn steps by default. Set include_steps: false for totals only.
maps_search_places and maps_search_nearby accept a fields array that replaces the default mask entirely, for either trimming cost or reaching fields the default omits.
maps_place_id_lookup resolves a place ID through Geocoding instead of Place Details when only the address is needed.
Set a quota cap in Google Cloud Console before pointing an autonomous agent at this server.
The classic web services (Geocoding, Elevation, Time Zone) answer HTTP 200 even when they refuse a request, with the real result in a status field. This server checks that field, so a bad key surfaces as a tool error instead of an empty success.
ZERO_RESULTS is returned as data, not as an error. An empty results array means the address or route genuinely has no match.
routingPreference and the avoid_* flags only apply to DRIVE and TWO_WHEELER. Passing them with WALK, BICYCLE or TRANSIT is rejected locally rather than sent to the API.
maps_distance_matrix results carry originIndex and destinationIndex and are not necessarily ordered.
MIT
Compute a route with turn-by-turn steps between two points, with optional waypoints. Supports DRIVE, WALK, BICYCLE, TWO_WHEELER and TRANSIT, live traffic for the motorised modes, toll/highway/ferry avoidance, alternative routes and waypoint order optimisation. Origin, destination and waypoints each accept an address, "latitude,longitude", or "place_id:...". Set include_steps=false when only total time and distance matter.
| Name | Required | Description | Default |
|---|---|---|---|
| units | No | Units in the instructions, default METRIC. | |
| origin | Yes | Start of the route. Address ("Bern main station"), coordinates ("46.9480,7.4474") or a place ID ("place_id:ChIJ..."). | |
| waypoints | No | Optional stops along the way, in order. Each one: Address ("Bern main station"), coordinates ("46.9480,7.4474") or a place ID ("place_id:ChIJ..."). | |
| avoid_tolls | No | Avoid toll roads (motorised modes only). | |
| destination | Yes | End of the route. Address ("Bern main station"), coordinates ("46.9480,7.4474") or a place ID ("place_id:ChIJ..."). | |
| region_code | No | CLDR region code, e.g. "CH". | |
| travel_mode | No | Travel mode, default DRIVE. | |
| alternatives | No | Return alternative routes as well. | |
| arrival_time | No | RFC 3339 UTC arrival timestamp. TRANSIT only, and mutually exclusive with departure_time. | |
| avoid_ferries | No | Avoid ferries (motorised modes only). | |
| include_steps | No | Include turn-by-turn steps, default true. Set false for totals only, which is cheaper. | |
| language_code | No | ISO 639 language code for the instructions, e.g. "de". | |
| transit_modes | No | TRANSIT only, restrict the vehicle types considered. | |
| avoid_highways | No | Avoid highways (motorised modes only). | |
| departure_time | No | RFC 3339 UTC timestamp, e.g. "2026-08-13T07:30:00Z". Must be in the future. | |
| routing_preference | No | Traffic handling for DRIVE and TWO_WHEELER, default TRAFFIC_AWARE. TRAFFIC_AWARE_OPTIMAL is slower and costs more. Ignored for the other modes. | |
| optimize_waypoint_order | No | Let the API reorder the waypoints for the shortest total route. | |
| transit_routing_preference | No | TRANSIT only, what to optimise for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only safety profile is covered. The description adds behavioral context about live traffic being available for motorised modes, and notes that setting include_steps=false is 'cheaper'—useful cost/performance information beyond the annotations.
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 three sentences long, front-loads the core purpose, and packs in essential capabilities without fluff. Every sentence earns its place, making it concise and well-structured for an 18-parameter tool.
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 high complexity (18 parameters, no output schema), the description partially covers what the tool returns—turn-by-turn steps or total time and distance—but does not describe the full response structure, alternative route behavior, or other return fields. While input semantics are well covered, the return value gap makes 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?
Schema description coverage is 100%, so the baseline is 3. The description adds some clarification about accepted formats for origin/destination/waypoints and that include_steps=false gives totals, but much of this is already present in the schema. It does not provide significant additional meaning beyond structured definitions.
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 computes a route with turn-by-turn steps, listing supported travel modes and key features like live traffic and avoidance options. This specific verb+resource distinguishes it from sibling tools such as maps_distance_matrix or maps_geocode.
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 gives clear context for the tool's main use (route computation with optional waypoints and modes) but does not explicitly mention when to use it over alternatives like maps_distance_matrix. The note 'Set include_steps=false when only total time and distance matter' is a parameter-level hint, not a tool-level alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Travel time and distance for every origin-destination pair, e.g. which of five depots is closest to a customer. Results carry originIndex and destinationIndex pointing back at the input arrays, and are not necessarily in order. Limit is 625 elements (origins x destinations), 100 for TRANSIT or TRAFFIC_AWARE_OPTIMAL.
| Name | Required | Description | Default |
|---|---|---|---|
| units | No | Units, default METRIC. | |
| origins | Yes | Start points. Each one: Address ("Bern main station"), coordinates ("46.9480,7.4474") or a place ID ("place_id:ChIJ..."). | |
| avoid_tolls | No | Avoid toll roads (motorised modes only). | |
| region_code | No | CLDR region code, e.g. "CH". | |
| travel_mode | No | Travel mode, default DRIVE. | |
| destinations | Yes | End points. Each one: Address ("Bern main station"), coordinates ("46.9480,7.4474") or a place ID ("place_id:ChIJ..."). | |
| avoid_ferries | No | Avoid ferries (motorised modes only). | |
| language_code | No | ISO 639 language code, e.g. "de". | |
| avoid_highways | No | Avoid highways (motorised modes only). | |
| departure_time | No | RFC 3339 UTC timestamp, e.g. "2026-08-13T07:30:00Z". Must be in the future. | |
| routing_preference | No | Traffic handling for DRIVE and TWO_WHEELER, default TRAFFIC_AWARE. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable non-obvious behavior: results are not necessarily in order, they carry originIndex/destinationIndex, and there are explicit element limits (625 general, 100 for transit/traffic-aware-optimal). These details go well beyond the annotation hints.
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?
Three sentences, each carrying distinct information: purpose, result structure/ordering, and limits. No filler or redundancy.
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 covers purpose, an example, key output characteristics, and hard limits. It doesn't fully expand the result fields (e.g., duration and distance), but the first sentence implies those, and the output schema absence is mitigated by the clear 'travel time and distance' phrasing.
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?
With 100% schema description coverage, the baseline is 3, but the description adds meaningful constraint: the product of origins and destinations is limited (625 max, 100 for certain modes). This gives practical semantics to the array parameters beyond what the schema states.
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 opens with 'Travel time and distance for every origin-destination pair,' which is a specific verb+resource statement and clearly differentiates this from single-route tools like maps_directions. The depot example reinforces the pairwise use case.
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 example 'which of five depots is closest to a customer' provides clear contextual guidance for when to use this tool. It doesn't explicitly name alternatives or exclusions, but the context is strong enough to convey the typical use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Elevation in metres above sea level for up to 100 coordinate pairs. Pass samples together with two or more locations to get an evenly spaced elevation profile along that path.
| Name | Required | Description | Default |
|---|---|---|---|
| samples | No | Turn the locations into a path and sample this many evenly spaced points along it (elevation profile). Needs at least two locations. | |
| locations | Yes | Coordinate pairs as "latitude,longitude", e.g. ["46.9480,7.4474", "45.9763,7.6586"]. Up to 100 per call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral details about the samples parameter creating an evenly spaced profile and the 100-pair limit, without contradicting the annotations.
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 convey the purpose, limits, and profile mode without any 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?
For a simple read-only tool with two parameters and no output schema, the description sufficiently covers the unit, limits, and the optional profile mode. It could specify the response structure, but the current level is adequate.
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?
Both parameters are fully described in the schema (locations, samples). The description reinforces the profile behavior and limit but adds little new semantic meaning beyond the schema.
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 returns elevation in metres for up to 100 coordinate pairs and describes the optional profile feature when samples are provided. It distinguishes itself from sibling tools by being the only elevation-related tool.
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 both usage modes: direct elevation queries for coordinate pairs and profile generation when samples and at least two locations are supplied. It doesn't explicitly mention alternatives, but the context makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an address into coordinates, plus the normalised address components, place ID and viewport. Narrow ambiguous addresses with components, e.g. "country:CH". An empty results array means ZERO_RESULTS, not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| bounds | No | Optional viewport bias "swLat,swLng|neLat,neLng". | |
| region | No | CLDR region code biasing the result, e.g. "ch". | |
| address | Yes | Address or place name to locate, e.g. "Bundesplatz 3, 3005 Bern, Switzerland". | |
| language | No | ISO 639 language code for the formatted address. | |
| components | No | Optional component filter narrowing the search, e.g. "country:CH" or "country:CH|postal_code:3033". Useful when the same street name exists in several countries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnly and openWorld, so the description adds value by explaining the ZERO_RESULTS behavior and the output contents (normalised components, place ID, viewport). It does not contradict annotations and provides useful, non-obvious 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?
The description is three compact sentences, each earning its place: purpose, usage tip, and error-behavior note. It is front-loaded with the core function and contains no filler.
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 absence of an output schema, the description reasonably covers what the tool returns (coordinates, components, place ID, viewport) and a key edge case (empty array = ZERO_RESULTS). It could detail the output structure further, but it is sufficient for the tool's complexity.
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 the baseline is 3. The description adds a brief usage tip for the components parameter, but most parameter meaning is already in the schema. It does not significantly deepen understanding 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?
The description clearly states the tool converts an address into coordinates and lists additional outputs (normalised components, place ID, viewport). This distinguishes it from sibling tools like maps_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?
The description gives specific usage context, such as using components to narrow ambiguous addresses, e.g. 'country:CH'. It does not name alternative tools, but the core use case is clear. The 'ZERO_RESULTS' note also guides error interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn partially typed text into place suggestions with their place IDs. Cheaper and faster than a full search when the goal is only to resolve what the user meant, e.g. an ambiguous street or city name.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Partial text typed so far, e.g. "bahnhofstr". | |
| latitude | No | Optional bias centre latitude. | |
| longitude | No | Optional bias centre longitude. | |
| region_code | No | CLDR region code biasing suggestions, e.g. "CH". | |
| language_code | No | ISO 639 language code for the suggestions. | |
| radius_meters | No | Optional bias radius in metres (max 50000). | |
| included_types | No | Optional primary type filter, e.g. ["street_address"] or ["locality"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds performance behavior ('cheaper and faster than a full search') and output content ('place suggestions with their place IDs'), going beyond the annotations without contradicting them.
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 exactly two sentences, front-loaded with the core purpose, and every clause adds value. 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 7 well-documented parameters and no output schema, the description covers the primary purpose, use case, and return type. It could mention behavior for no results or exact response format, but it is complete enough for an autocomplete 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?
The schema covers 100% of parameters with detailed descriptions and examples. The description itself does not add parameter-level 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 ('Turn') and clearly identifies the resource: partially typed text into place suggestions with place IDs. It distinguishes from siblings by stating it is 'cheaper and faster than a full search' and by scoping to resolving ambiguous input.
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?
It provides explicit usage context: 'when the goal is only to resolve what the user meant' with examples like 'ambiguous street or city name.' It references 'full search' as an alternative but does not explicitly name sibling tools or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for one place ID: address components, phone numbers, website, opening hours, rating and business status. Set include_reviews to also get user reviews and the editorial summary, which costs more. Get the place ID from maps_search_places, maps_search_nearby, maps_geocode or maps_place_autocomplete.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Optional field mask overriding the default response fields. Extra fields can raise the billing tier, e.g. "reviews" moves the call to the Enterprise + Atmosphere SKU. | |
| place_id | Yes | Place ID from maps_search_places, maps_search_nearby, maps_geocode or maps_place_autocomplete. | |
| region_code | No | CLDR region code affecting address formatting. | |
| language_code | No | ISO 639 language code for the response. | |
| include_reviews | No | Add reviews and editorial summary to the response. This raises the call to the Enterprise + Atmosphere billing tier, so only set it when the reviews are actually needed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds valuable behavioral context about the include_reviews parameter raising the billing tier, and it enumerates the default fields returned. It does not contradict annotations, and while it does not detail error behavior or output structure, the added cost disclosure goes beyond the annotations.
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 three tightly packed sentences. The first sentence front-loads the primary action and result fields, the second adds a key cost caveat, and the third explains the prerequisite source of place IDs. No filler or redundancy—every sentence earns its place.
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?
For a read-only details tool with high schema coverage and informative annotations, the description is complete. It states the purpose, lists the default return fields, warns about the cost of include_reviews, and tells the user where to obtain the required place_id. No output schema exists, but the description enumerates the key returned content, and the schema covers parameters fully.
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%, with every parameter (place_id, fields, region_code, language_code, include_reviews) already described in the input schema. The tool description adds no new parameter-level meaning; it merely repeats the include_reviews cost note already present in the schema. Baseline of 3 is appropriate since the schema fully documents the 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 states exactly what the tool does: 'Full detail for one place ID' followed by a concrete list of returned fields (address components, phone numbers, website, opening hours, rating, business status). It clearly distinguishes itself from sibling tools by noting the place ID must come from maps_search_places, maps_search_nearby, maps_geocode, or maps_place_autocomplete, making the purpose unambiguous.
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 provides clear context for when to use this tool: when you have a place ID from one of the listed search/geocode/autocomplete tools and need full details. It also gives usage guidance about include_reviews costing more, implying it should only be set when reviews are truly needed. However, it does not explicitly compare against the sibling maps_place_id_lookup, so exclusion of alternatives is not fully addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a place ID to its address and coordinates through the Geocoding API. Cheaper than maps_place_details when only the location is needed, but it returns no opening hours, phone number, rating or website.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ISO 639 language code for the formatted address. | |
| place_id | Yes | Google place ID, e.g. "ChIJ...". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world hints. The description adds meaningful behavioral context: it uses the Geocoding API, returns address/coordinates, and explicitly lists fields it does NOT return. No contradictions. It stops short of detailing rate limits or exact return structure, but the safety profile is already covered.
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 succinct sentences, front-loaded with the core action, then a useful efficiency/caveat comparison. Every word earns its place.
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?
For a simple 2-parameter tool with no output schema, the description covers purpose, usage context, limitations, and expected result (address and coordinates). It is fully sufficient 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both place_id and language described in the schema. The description does not add parameter-level details beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a place ID to address and coordinates via the Geocoding API, using a specific verb and resource. It also distinguishes itself from the sibling maps_place_details by noting it is cheaper but returns fewer fields.
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?
Explicitly provides when-to-use guidance by comparing to maps_place_details: use when only location is needed, and avoid when opening hours, phone, rating, or website are required. This directly helps the agent choose between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert coordinates into the addresses at that point, ordered from most to least specific. Filter with result_type (e.g. "street_address") or location_type (e.g. "ROOFTOP") when only one kind of match is useful.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ISO 639 language code for the formatted address. | |
| location | Yes | Coordinates as "latitude,longitude", e.g. "46.9480,7.4474". | |
| result_type | No | Optional address type filter, e.g. "street_address" or "locality|postal_code". | |
| location_type | No | Optional precision filter: ROOFTOP, RANGE_INTERPOLATED, GEOMETRIC_CENTER or APPROXIMATE. Values can be combined with "|". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description does not need to re-state safety. It adds useful context about result ordering (most to least specific) and filter usage, but does not disclose pagination, error behavior, or output structure beyond that.
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: first states the core function, second offers filter guidance. No wasted words, front-loaded with 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 adequately communicates what is returned (addresses) and how to narrow results. It does not explain return formats, but for a reverse geocoding tool this level of detail is sufficient for an agent to invoke it correctly.
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 each parameter already described. The description adds examples for result_type and location_type, but these are illustrative rather than additional semantic meaning. 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 the tool converts coordinates into addresses, which is specific and action-oriented. It implicitly distinguishes from forward geocoding (maps_geocode) by emphasizing coordinates-to-address direction, though it does not explicitly name an alternative.
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 usage for when you have coordinates and need addresses, and explains when to use filters (result_type, location_type). However, it does not explicitly contrast with sibling tools like maps_geocode or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List places inside a circle around a coordinate, optionally filtered by type (e.g. ["cafe", "bakery"]). Unlike maps_search_places the radius is a hard restriction, so this is the tool for "what is within 500 m of here" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Optional field mask overriding the default response fields. Extra fields can raise the billing tier, e.g. "reviews" moves the call to the Enterprise + Atmosphere SKU. | |
| rank_by | No | Ranking within the circle, default POPULARITY. | |
| latitude | Yes | Centre latitude of the search circle. | |
| longitude | Yes | Centre longitude of the search circle. | |
| max_results | No | Maximum number of results, 1 to 20 (default 10). | |
| region_code | No | CLDR region code, e.g. "CH". | |
| language_code | No | ISO 639 language code for the response. | |
| radius_meters | Yes | Search radius in metres (max 50000). Unlike maps_search_places this is a hard restriction. | |
| excluded_types | No | Optional place types to exclude. | |
| included_types | No | Optional place types to include, e.g. ["cafe", "bakery"]. Omit for all types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description focuses on the key behavior that the radius is a hard restriction, not a suggestion. It also mentions optional type filtering, adding context beyond annotations, though it doesn't disclose response format or potential billing implications (the latter is covered in the schema).
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: the first states function, the second gives a contrast and a concrete usage example. No fluff or redundancy.
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?
Despite having 10 parameters and no output schema, the description communicates the essential function, the key behavioral constraint (hard radius), and the intended use case. The schema handles parameter details, so the description is sufficient 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 10 parameters, including `included_types` and `radius_meters`. The description's mention of type filtering and circle radius maps to these but adds no new syntax or constraints, so the baseline of 3 applies.
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 opens with 'List places inside a circle around a coordinate,' which is a specific verb+resource+scope. It also explicitly differentiates from the sibling tool maps_search_places by noting the radius is a hard restriction, making the purpose unmistakable.
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 names the alternative tool (maps_search_places) and provides a concrete use-case scenario ('what is within 500 m of here'), making it clear when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search places by free-form text, e.g. "vegan restaurant in Bern" or "pharmacy open now". Returns name, address, coordinates, place ID, rating and price level per hit. Bias results toward an area with latitude + longitude + radius_meters, and page through more results with the returned nextPageToken. Use maps_search_nearby instead when the search must stay strictly inside a radius.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-form search text, e.g. "vegan restaurant in Bern" or "hardware store near me". | |
| fields | No | Optional field mask overriding the default response fields. Extra fields can raise the billing tier, e.g. "reviews" moves the call to the Enterprise + Atmosphere SKU. | |
| rank_by | No | Result ranking. DISTANCE needs the bias centre to be set. | |
| latitude | No | Optional bias centre latitude. Pass together with longitude and radius_meters. | |
| open_now | No | Optional, keep only places open at request time. | |
| longitude | No | Optional bias centre longitude. | |
| min_rating | No | Optional minimum average rating, 0 to 5 in 0.5 steps. | |
| page_token | No | nextPageToken from a previous call, for paging. | |
| max_results | No | Results per page, 1 to 20 (default 10). | |
| region_code | No | CLDR region code biasing results, e.g. "CH". | |
| price_levels | No | Optional price level filter. | |
| included_type | No | Optional single place type filter, e.g. "restaurant", "pharmacy", "electric_vehicle_charging_station". | |
| language_code | No | ISO 639 language code for the response, e.g. "de". | |
| radius_meters | No | Optional bias radius in metres (max 50000). Results outside are still possible. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds behavioral nuance: results are 'biased' toward the area, not strictly confined, and mentions pagination via nextPageToken. It doesn't cover rate limits or auth, but given the annotations, this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with front-loaded purpose, examples, return info, and usage guidance. No wasted words; every sentence contributes.
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 covers the core return fields, bias behavior, pagination, and differentiates from the sibling tool. While it doesn't enumerate all filters (e.g., open_now, price_levels), the schema provides those details. Given the tool's complexity and no output schema, this is a strong description.
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 value by explaining that latitude/longitude/radius_meters are a 'bias' and that nextPageToken enables paging, clarifying semantics that go beyond the schema's field 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?
The description uses a specific verb and resource: 'Search places by free-form text' with concrete examples like 'vegan restaurant in Bern'. It clearly distinguishes from maps_search_nearby by contrasting bias vs. strict radius, and mentions the return fields, making the purpose unambiguous.
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 when to use this tool and when to use the alternative: 'Use maps_search_nearby instead when the search must stay strictly inside a radius.' It also explains how to bias results and paginate, providing actionable usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Time zone ID, name and UTC offset for a coordinate, including the daylight saving offset at the given moment. Pass timestamp when asking about a past or future date, since the DST offset depends on it.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ISO 639 language code for the time zone name. | |
| location | Yes | Coordinates as "latitude,longitude", e.g. "46.9480,7.4474". | |
| timestamp | No | Unix timestamp in seconds, defaults to now. It decides whether daylight saving time is in effect, so pass the actual moment when asking about a past or future date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral nuance: the result includes the daylight saving offset and is time-dependent. This goes beyond the annotation by explaining the DST nuance, though it doesn't detail edge cases like invalid coordinates.
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 focused sentences. The first states the core purpose and output, the second gives crucial usage guidance. No fluff or repetition.
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?
Despite lacking an output schema, the description tells the user exactly what information will be returned and explains the time-dependence. For a simple lookup tool, this is complete and self-contained.
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. The description adds value by clarifying the output (time zone name, UTC offset) and emphasizing the timestamp's role in determining DST, which is not fully apparent from the schema alone.
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 returns 'Time zone ID, name and UTC offset for a coordinate' with a specific verb implied ('returns'). This distinguishes it from sibling tools like geocoding or place search, which serve different purposes.
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 clear usage guidance about passing a timestamp for past/future dates due to DST dependency. Does not explicitly mention when not to use or name alternatives, but the tool's unique function among siblings makes the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: search, nearby search, place details, autocomplete, geocoding, reverse geocoding, place ID lookup, directions, distance matrix, elevation, and timezone. Even the two search tools are explicitly differentiated (free text vs. strict radius), and place details vs. place ID lookup are distinguished by data richness.
All tools use the maps_ prefix with snake_case, but the pattern varies: some are verb_noun (search_places, place_details) while others are noun-only (elevation, timezone). Overall the naming is predictable and readable, but not perfectly uniform.
11 tools is a well-scoped size for a Maps server, covering the core Google Maps APIs without bloat. Each tool earns its place and the set feels neither sparse nor overwhelming.
The surface is remarkably complete for a read-only Maps API server: it includes place search and details, geocoding (forward and reverse), place ID resolution, directions, distance matrix, elevation, and timezone. No obvious missing operations that an agent would commonly need.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Google Maps MCP Pack — geocoding, places, directions, distance matrix, elevation.
Ground your AI applications with trusted geospatial data from Google Maps.
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.
4 Google Maps endpoints. Pay per call in USDC via x402.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AIWerk/mcp-server-google-maps'
If you have feedback or need assistance with the MCP directory API, please join our Discord server