Hosted MCP for live place search, geocoding & turn-by-turn routes. No Maps API key to manage.
Scored across 5 tools
Each tool has a clearly distinct purpose: routing (directions), address/coordinate conversion (geocode), single-place lookup by ID (places_details), radius search with existing coordinates (places_nearby), and free-text discovery (places_search_text). The descriptions explicitly cross-reference each other to resolve the one plausible overlap (nearby vs. search_text).
The three place_* tools follow a clean prefix_noun convention, and all names are lowercase snake_case. However, directions and geocode stand apart as bare verbs rather than following a uniform pattern, a minor deviation but still readable and predictable.
Five tools is well-scoped for a maps/location server, and each tool covers a genuinely distinct capability (routing, geocoding, text search, nearby search, place details). No tool feels redundant or padded.
Covers the core lifecycle: forward/reverse geocoding, routing, place discovery (text and nearby), and place details with phone/website/hours. Minor gaps exist (no autocomplete/predictions, distance matrix, or time zone/elevation), but agents can work around these for most workflows.
Compute a route from origin to destination by DRIVE, WALK, BICYCLE, TRANSIT, or TWO_WHEELER. Use when the user asks how to get somewhere, how far it is, or how long it takes. Origin and destination may be an address string, "lat,lng", or an object with place_id. Returns total duration and distance, an encoded polyline, and per-leg turn-by-turn steps (maneuver, instruction text, distance, duration, start/end lat/lng).
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Address string, 'lat,lng', or {address|place_id|latitude,longitude} | |
| field_mask | No | Optional Routes X-Goog-FieldMask override. Default includes turn-by-turn navigationInstruction without Pro fields (localizedValues, travelAdvisory). | |
| destination | Yes | Address string, 'lat,lng', or {address|place_id|latitude,longitude} | |
| travel_mode | No | DRIVE, WALK, BICYCLE, TRANSIT, TWO_WHEELER | |
| alternatives | No | ||
| intermediates | No | ||
| language_code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent, open-world read, so the description need not restate safety. It adds value by describing the return payload (total duration/distance, encoded polyline, per-leg turn-by-turn steps) and the accepted origin/destination input formats, which is real behavioral context beyond the structured fields.
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 tight sentences with no filler: capability first, activation conditions second, return shape last. Densely packed but each sentence carries distinct information.
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?
With no output schema, the description appropriately explains the response shape, and it covers routing intent and input formats. It leaves the semantics of alternatives, intermediates, and language_code unexplained, a minor gap for a 7-param 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?
At 57% schema coverage the description meaningfully supplements the two required params, spelling out that origin/destination accept an address string, 'lat,lng', or a place_id object, and listing the travel_mode values. It says nothing about alternatives, intermediates, language_code, or field_mask, leaving those to 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?
Names a precise verb+resource (compute a route from origin to destination) and enumerates the five supported travel modes. The purpose is unmistakable next to the sibling tools geocode and places_*, which handle geocoding and place lookup rather than routing.
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 states the triggering intents: 'how to get somewhere, how far it is, or how long it takes.' That is a clear when-to-use, though it names no explicit exclusions or alternatives among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an address to lat/lng (forward: pass address), or lat/lng to an address (reverse: pass latitude and longitude). Use when the user needs coordinates or a normalized address, or before places_nearby. To find businesses use places_search_text; directions accepts addresses directly, so geocoding first is not required. Returns formatted address, lat/lng, place_id, types, and plus code.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Address to forward-geocode | |
| latitude | No | Latitude for reverse geocode | |
| longitude | No | Longitude for reverse geocode | |
| field_mask | No | ||
| language_code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds real value by disclosing the return shape (formatted address, lat/lng, place_id, types, plus code) and by clarifying that geocoding is not a prerequisite for directions. It omits rate limits, quota, or key/auth requirements, so it stops short of a 5.
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?
Front-loaded with the core operation, then usage, alternatives, and return values in tight, information-dense sentences. Every clause carries distinct value (routing advice, return shape), with no repetition of the name or 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?
With no output schema, the description compensates by enumerating the returned fields, and it covers both invocation modes plus sibling routing. For a read-only 5-parameter tool with annotations covering safety, nothing an agent needs to call it correctly is missing.
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 documents address/latitude/longitude but does not state that they are alternatives selected by direction of the lookup; the description supplies exactly that conditional semantics ('forward: pass address', 'reverse: pass latitude and longitude'). field_mask and language_code remain undocumented in both places, which is the only gap.
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?
States a specific verb+resource ('convert an address to lat/lng' and the reverse) and explicitly names both operation modes, so an agent immediately understands the bidirectional behavior. It is clearly distinguishable from siblings by naming places_search_text and directions directly.
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?
Gives explicit when-to-use ('the user needs coordinates or a normalized address, or before places_nearby') and when-not-to-use ('To find businesses use places_search_text; directions accepts addresses directly, so geocoding first is not required'). Nothing is left to inference about routing between this and its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for one known place by place_id (from places_search_text or places_nearby). Use when the user asks for a specific place's phone number, website, opening hours, or rating. Returns name, formatted address, lat/lng, rating, opening hours, phone, website, and attributions.
| Name | Required | Description | Default |
|---|---|---|---|
| place_id | Yes | Place id, with or without the places/ prefix | |
| field_mask | No | ||
| language_code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds no behavioral context beyond listing return fields, which repeats what could be inferred from an output schema that doesn't exist. For a read-only lookup, the safety profile is fully covered by annotations, so this is a significant gap.
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 with no waste, front-loading the core action and then providing usage context. It could be slightly more concise by merging the return-fields list, but overall 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?
With no output schema, the description lists return fields, which is helpful. However, for a tool with three parameters and only 33% schema coverage, it fails to explain the two undocumented parameters (field_mask, language_code), leaving the definition incomplete for correct invocation.
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 required place_id is covered by the schema description ('Place id, with or without the places/ prefix'), but the other two parameters (field_mask, language_code) have 0% schema description coverage. The description doesn't mention these parameters or their purpose, leaving the agent without guidance on how to use field_mask for response shaping or language_code for localization.
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 a specific verb ('Get details') and resource ('one known place'), and explicitly identifies the source of the place_id (places_search_text or places_nearby), distinguishing it from siblings like places_nearby and places_search_text.
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 gives a clear when-to-use condition ('Use when the user asks for a specific place's phone number, website, opening hours, or rating') and names the sibling tools that produce the required place_id, effectively preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List places within a radius (meters) of a lat/lng you already have, such as the user's location or a geocode result, optionally filtered by Places types (e.g. ["restaurant"]) and ranked by DISTANCE or POPULARITY. For free-text, name, or city queries use places_search_text instead. Returns place_id, name, formatted address, lat/lng, types, rating, opening hours, and attributions.
| Name | Required | Description | Default |
|---|---|---|---|
| radius | Yes | Circle radius in meters | |
| latitude | Yes | ||
| longitude | Yes | ||
| field_mask | No | ||
| language_code | No | ||
| included_types | No | Places types, e.g. ["restaurant"] | |
| rank_preference | No | DISTANCE or POPULARITY | |
| max_result_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds behavior beyond that: it discloses the ordering options (DISTANCE or POPULARITY) and enumerates the returned fields (place_id, name, formatted address, lat/lng, types, rating, opening hours, attributions), which is the only return-value documentation available since no output schema exists.
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 dense sentences that are front-loaded with the core capability and then the routing rule and return fields. Every clause earns its place, though the return-value enumeration makes the second sentence long.
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?
With no output schema, the description usefully enumerates return fields and covers when to use this vs. the text-search sibling. It falls short on the meaning of several search-shaping parameters (field_mask, language_code, max_result_count), but an agent could still call the required lat/lng/radius path 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 only 38%, so the description carries the compensation burden. It restates what the schema already documents (radius in meters, included_types example, rank values) but says nothing about field_mask, language_code, or max_result_count, leaving the majority of parameters undocumented in both places.
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?
States a specific verb and resource ('List places within a radius ... of a lat/lng') plus scope (geographic radius search, optionally filtered by type, ranked by distance/popularity). It explicitly names the sibling it is not (places_search_text) for free-text/name/city queries, so an agent can differentiate it without opening a schema.
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?
Gives the precondition ('a lat/lng you already have, such as the user's location or a geocode result') and an explicit exclusion routing rule ('For free-text, name, or city queries use places_search_text instead'). Both when-to-use and when-not-to-use with a named alternative are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find places by free text: a business name, a category, or "X in/near Y" (e.g. "coffee in Porto", "pharmacies near Lisbon Oriente"). Default choice for finding places. Use places_nearby only when you already have exact coordinates. Returns up to 20 places, each with place_id, name, formatted address, lat/lng, types, rating, opening hours (open_now and weekly hours), and attributions. Pass a place_id to places_details for phone or website.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text query, e.g. 'coffee in Austin' | |
| radius | No | Optional location bias radius in meters | |
| latitude | No | Optional location bias latitude | |
| longitude | No | Optional location bias longitude | |
| field_mask | No | ||
| included_type | No | Optional Places type filter | |
| language_code | No | ||
| max_result_count | No | 1-20 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, so safety is covered; the description adds the result cap ('up to 20 places') and enumerates the returned fields, which is real behavioral context beyond the annotations. It doesn't mention rate limits or pagination, keeping it short of a 5.
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?
Four sentences, front-loaded with the core selection rule, then alternative routing, then return shape, then the handoff. No filler and no repetition of the tool name.
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 search tool with no output schema, the description supplies return-field detail and the downstream chain to places_details, which is what an agent needs to plan a call. It stops short of covering the two undocumented parameters or pagination behavior.
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 75% and the schema already documents query, radius, lat/lng, included_type and max_result_count. The description adds only the max=20 constraint and positional bias intent, which is roughly baseline for this coverage level. field_mask and language_code remain undocumented in both places.
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?
Opens with a specific verb+resource ('Find places by free text') and immediately disambiguates the sibling by naming places_nearby and the exact condition that selects it ('only when you already have exact coordinates'). An agent can route between the two tools without opening either schema.
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 declares itself the 'Default choice for finding places' and gives the exclusion rule for the alternative tool. It also hands off to places_details for phone/website, so the multi-step workflow is covered.
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.
directionsgeocodeplaces_detailsplaces_nearbyplaces_search_textHERE MCP — premium geocoding, places, and TRAFFIC-AWARE routing from HERE
Geoapify MCP — wraps the Geoapify Location Platform (geoapify.com)
Geocode, reverse-geocode, autocomplete, route and search places.
Google Maps MCP Pack — geocoding, places, directions, distance matrix, elevation.
Add one secure layer between your agents and this server.