mcp
Server Details
Ground your AI applications with trusted geospatial data from Google Maps.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 3 of 3 tools scored.
Each tool has a distinct and non-overlapping purpose: compute_routes handles travel routing, lookup_weather provides weather data, and search_places finds locations. Their descriptions clearly differentiate them, with no ambiguity in functionality.
All tool names follow a consistent verb_noun pattern (compute_routes, lookup_weather, search_places). The naming is uniform, using snake_case throughout, with no deviations or mixed conventions.
With only 3 tools, the set feels thin for a general-purpose MCP server, potentially limiting functionality. However, each tool is well-defined and serves a clear purpose, making the count borderline but not severely inadequate.
The tools cover core location-based services (search, routing, weather) effectively, with no major gaps in their respective domains. Minor gaps might include advanced features like traffic updates or historical weather, but basic workflows are well-supported.
Available Tools
3 toolscompute_routesARead-onlyInspect
Computes a travel route between a specified origin and destination. Supported Travel Modes: DRIVE (default), WALK.
Input Requirements (CRITICAL): Requires both origin and destination. Each must be provided using one of the following methods, nested within its respective field:
address: (string, e.g., 'Eiffel Tower, Paris'). Note: The more granular or specific the input address is, the better the results will be.
lat_lng: (object, {"latitude": number, "longitude": number})
place_id: (string, e.g., 'ChIJOwE_Id1w5EAR4Q27FkL6T_0') Note: This id can be obtained from the search_places tool. Any combination of input types is allowed (e.g., origin by address, destination by lat_lng). If either the origin or destination is missing, you MUST ask the user for clarification before attempting to call the tool.
Example Tool Call: {"origin":{"address":"Eiffel Tower"},"destination":{"place_id":"ChIJt_5xIthw5EARoJ71mGq7t74"},"travel_mode":"DRIVE"}
The grounded output must be attributed to the source using the information from the
attributionfield when available.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Required. Origin waypoint. | |
| travelMode | No | Optional. Specifies the mode of transportation. | |
| destination | Yes | Required. Destination waypoint. |
Output Schema
| Name | Required | Description |
|---|---|---|
| routes | No | Contains routes between the requested origin and destination. Currently only one route is returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations. While annotations indicate read-only and non-destructive operations, the description specifies supported travel modes (DRIVE and WALK), notes that WALK routes are in beta with potential issues, and emphasizes the critical requirement for both origin and destination inputs. It also provides an example tool call, enhancing clarity. No contradictions with annotations are present.
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 well-structured and front-loaded, starting with the core purpose, followed by supported modes, input requirements, and an example. Each section is concise and informative, with no wasted sentences. The use of bold text for key points and clear bullet points enhances readability without adding unnecessary length.
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 complexity of the tool (3 parameters, nested objects, and an output schema), the description is complete. It covers the purpose, input requirements, behavioral notes (e.g., travel modes and beta warnings), and usage guidance. With an output schema present, it appropriately omits return value details, focusing instead on input semantics and operational context, making it fully adequate for agent 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?
With 100% schema description coverage, the baseline is 3, but the description adds significant semantic value. It explains the three input methods for origin and destination (address, lat_lng, place_id), provides examples and notes on granularity, and clarifies that any combination is allowed. It also stresses the requirement to ask for clarification if inputs are missing, which is not covered in the schema. This compensates well for the high schema coverage.
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's purpose: 'Computes a travel route between a specified origin and destination.' It specifies the verb 'computes' and the resource 'travel route,' and distinguishes itself from sibling tools like 'lookup_weather' and 'search_places' by focusing on route calculation rather than weather data or place searches.
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 usage by stating that both origin and destination are required and must be provided using specific methods (address, lat_lng, or place_id). It also mentions that place_id can be obtained from the 'search_places' tool, offering a practical alternative. However, it does not explicitly state when not to use this tool or compare it directly to other routing alternatives beyond the sibling tools listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_weatherARead-onlyInspect
Retrieves comprehensive weather data including current conditions, hourly, and daily forecasts.
Specific Data Available: Temperature (Current, Feels Like, Max/Min, Heat Index), Wind (Speed, Gusts, Direction), Celestial Events (Sunrise/Sunset, Moon Phase), Precipitation (Type, Probability, Quantity/QPF), Atmospheric Conditions (UV Index, Humidity, Cloud Cover, Thunderstorm Probability), and Geocoded Location Address.
Location & Location Rules (CRITICAL):
The location for which weather data is requested is specified using the location field.
This field is a 'oneof' structure, meaning you MUST provide a value for ONLY ONE
of the three location sub-fields below to ensure an accurate weather data lookup.
Geographic Coordinates (lat_lng)
Use it when you are provided with exact lat/lng coordinates.
Example: {"location": {"lat_lng": {"latitude": 34.0522, "longitude": -118.2437}}} // Los Angeles
Place ID (place_id)
An unambiguous string identifier (Google Maps Place ID).
The place_id can be fetched from the search_places tool.
Example: {"location": {"place_id": "ChIJLU7jZClu5kcR4PcOOO6p3I0"}} // Eiffel Tower
Address String (address)
A free-form string that requires specificity for geocoding.
City & Region: Always include region/country (e.g., "London, UK", not "London").
Street Address: Provide the full address (e.g., "1600 Pennsylvania Ave NW, Washington, DC").
Postal/Zip Codes: MUST be accompanied by a country name (e.g., "90210, USA", NOT "90210").
Example: {"location": {"address": "1600 Pennsylvania Ave NW, Washington, DC"}}
Usage Modes:
Current Weather: Provide
locationonly. Do not specifydateandhour.Hourly Forecast: Provide
location,date, andhour(0-23). Use for specific times (e.g., "at 5 PM") or terms like "next few hours" or "later today". If the user specifies minute, round down to the nearest hour. Hourly forecast beyond 120 hours from now is not supported. Historical hourly weather is supported up to 24 hours in the past.Daily Forecast: Provide
locationanddate. Do not specifyhour. Use for general day requests (e.g., "weather for tomorrow", "weather on Friday", "weather on 12/25"). If today's date is not in the context, you should clarify it with the user. Daily forecast beyond 10 days including today is not supported. Historical weather is not supported.
Parameter Constraints:
Timezones: All
dateandhourinputs must be relative to the location's local time zone, not the user's time zone.Date Format: Inputs must be separated into
{year, month, day}integers.Units: Defaults to
METRIC. Setunits_systemtoIMPERIALfor Fahrenheit/Miles if the user implies US standards or explicitly requests it.The grounded output must be attributed to the source using the information from the
attributionfield when available.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional. The date of the required weather information. Note: This date is relative to the local timezone of the location specified in the location field. The date must be between 24 hours in the past and the next 10 days. | |
| hour | No | Optional. The hour of the requested weather information, in 24-hour format (0-23). This value is relative to the local timezone of the location specified in the location field. Hourly forecast beyond 120 hours from now is not supported. Historical hourly weather is supported up to 24 hours in the past. | |
| location | Yes | Required. The location to get the weather conditions for. | |
| unitsSystem | No | Optional. The units system to use for the returned weather conditions. If not provided, the returned weather conditions will be in the metric system (default = METRIC). |
Output Schema
| Name | Required | Description |
|---|---|---|
| wind | No | The wind conditions |
| uvIndex | No | The maximum ultraviolet (UV) index. define optional because it is not always available |
| heatIndex | No | The hourly heat index temperature. |
| sunEvents | No | The events related to the sun (e.g. sunrise, sunset). |
| cloudCover | No | The percentage of the sky covered by clouds (values from 0 to 100). define optional because it is not always available |
| moonEvents | No | The events related to the moon (e.g. moonrise, moonset). |
| airPressure | No | The hourly air pressure conditions. |
| attribution | No | Required attribution to show with the weather. |
| temperature | No | The hourly temperature |
| maxHeatIndex | No | The maximum heat index temperature throughout the day. |
| precipitation | No | The precipitation probability and amount of precipitation accumulated |
| maxTemperature | No | The maximum (high) temperature throughout the day. |
| minTemperature | No | The minimum (low) temperature throughout the day. |
| relativeHumidity | No | The percent of relative humidity (values from 0 to 100). define optional because it is not always available |
| returnedLocation | No | Required. The location where the weather information is returned. This location is identical to the location in the request, but can be different from it if the requested location is a free text address that looks up to a coarse location (e.g. "Mountain View, CA"). |
| weatherCondition | No | The weather condition |
| feelsLikeTemperature | No | The hourly measure of how the temperature feels like. |
| feelsLikeMaxTemperature | No | The maximum (high) feels-like temperature throughout the day. |
| feelsLikeMinTemperature | No | The minimum (low) feels-like temperature throughout the day. |
| thunderstormProbability | No | The thunderstorm probability (values from 0 to 100). define optional because it is not always available |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context beyond annotations: it specifies forecast time limits (48 hours for hourly, 7 days for daily), clarifies that historical weather is not supported, explains timezone handling relative to location, and provides unit system defaults and selection criteria. No contradiction with annotations 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?
The description is well-structured with clear sections (Specific Data Available, Location Rules, Usage Modes, Parameter Constraints) but is somewhat lengthy. Every sentence serves a purpose, and critical information is front-loaded, though some redundancy exists between the description and schema descriptions.
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 complexity (multiple usage modes, location options, time constraints) and the presence of both comprehensive annotations and an output schema, the description provides complete contextual information. It covers all critical aspects an agent needs to invoke the tool correctly, including edge cases and practical examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3, but the description adds significant semantic value: it explains the critical 'oneof' structure for location parameters with practical examples, clarifies address formatting requirements, provides rounding rules for hourly forecasts, and explains when to use each location type based on available data.
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 'retrieves comprehensive weather data including current conditions, hourly, and daily forecasts' with specific data elements listed. It distinguishes itself from sibling tools (compute_routes, search_places) by focusing exclusively on weather data retrieval rather than routing or place search.
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 explicit guidance on when to use each of the three usage modes (current weather, hourly forecast, daily forecast) with clear rules about which parameters to include/exclude. It also references the sibling tool search_places as a source for place_id values, creating clear workflow connections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_placesARead-onlyInspect
Call this tool when the user's request is to find places, businesses, addresses, locations, points of interest, or any other Google Maps related search.
Input Requirements (CRITICAL):
text_query(string - MANDATORY): The primary search query. This must clearly define what the user is looking for.Examples:
'restaurants in New York','coffee shops near Golden Gate Park','SF MoMA','1600 Amphitheatre Pkwy, Mountain View, CA, USA','pets friendly parks in Manhattan, New York','date night restaurants in Chicago','accessible public libraries in Los Angeles'.For specific place details: Include the requested attribute (e.g.,
'Google Store Mountain View opening hours','SF MoMa phone number','Shoreline Park Mountain View address').
location_bias(object - OPTIONAL): Use this to prioritize results near a specific geographic area.Format:
{"location_bias": {"circle": {"center": {"latitude": [value], "longitude": [value]}, "radius_meters": [value (optional)]}}}Usage:
To bias to a 5km radius:
{"location_bias": {"circle": {"center": {"latitude": 34.052235, "longitude": -118.243683}, "radius_meters": 5000}}}To bias strongly to the center point:
{"location_bias": {"circle": {"center": {"latitude": 34.052235, "longitude": -118.243683}}}}(omittingradius_meters).
language_code(string - OPTIONAL): The language to show the search results summary in.Format: A two-letter language code (ISO 639-1), optionally followed by an underscore and a two-letter country code (ISO 3166-1 alpha-2), e.g.,
en,ja,en_US,zh_CN,es_MX. If the language code is not provided, the results will be in English.
region_code(string - OPTIONAL): The Unicode CLDR region code of the user. This parameter is used to display the place details, like region-specific place name, if available. The parameter canaffect results based on applicable law.Format: A two-letter country code (ISO 3166-1 alpha-2), e.g.,
US,CA.
Instructions for Tool Call:
Location Information (CRITICAL): The search must contain sufficient location information. If the location is ambiguous (e.g., just "pizza places"), you must specify it in the
text_query(e.g., "pizza places in New York") or use thelocation_biasparameter. Include city, state/province, and region/country name if needed for disambiguation.Always provide the most specific and contextually rich
text_querypossible.Only use
location_biasif coordinates are explicitly provided or if inferring a location from a user's known context is appropriate and necessary for better results.The grounded output must be attributed to the source using the information from the
attributionfield when available.
| Name | Required | Description | Default |
|---|---|---|---|
| textQuery | Yes | Required. The text query. | |
| regionCode | No | Optional. The Unicode country/region code (CLDR) of the location where the request is coming from. This parameter is used to display the place details, like region-specific place name, if available. The parameter can affect results based on applicable law. For example, "US" for United States. For more information, see https://www.unicode.org/cldr/charts/latest/supplemental/territory_language_information.html. Note that 3-digit region codes are not currently supported. | |
| languageCode | No | Optional. The language to request that the summary is returned in. If the language code is unspecified or unrecognized, the summary with a preference for English will be returned. For example, "en" for English. Current list of supported languages: https://developers.google.com/maps/faq#languagesupport. | |
| locationBias | No | An optional region to bias the search results to. If an explicit location is in `text_query`, it will be used to bias the search results instead of this field. |
Output Schema
| Name | Required | Description |
|---|---|---|
| places | No | Output only. The list of places that are mentioned in the summary. |
| summary | No | Output only. A natural language summary of the search results. The summary may contain zero-based citations like "[0]", "[1]", "[2]" etc. These citations map to the corresponding places in the `places` field. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, non-idempotent, and closed-world behavior. The description adds valuable context beyond this: it emphasizes the critical need for location information in queries, provides usage examples, and explains how parameters like 'location_bias' affect results. It doesn't contradict annotations and enriches understanding of the tool's operation.
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 well-structured with clear sections (purpose, input requirements, instructions) and uses bullet points for readability. It is appropriately detailed for a complex tool but could be slightly more concise by reducing repetition in examples. Overall, it's front-loaded with critical information and efficiently organized.
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 complexity, rich input schema, annotations, and the presence of an output schema, the description is highly complete. It covers purpose, usage guidelines, parameter semantics, and behavioral context thoroughly. No gaps are evident; it provides all necessary information for an AI agent to use the tool effectively.
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%, but the description adds significant semantic value beyond the schema. It explains the mandatory nature of 'text_query' with examples, clarifies the optional use of 'location_bias' with formatting details, and provides context for 'language_code' and 'region_code' parameters, including practical usage scenarios and constraints.
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's purpose: 'find places, businesses, addresses, locations, points of interest, or any other Google Maps related search.' It specifies the verb ('find') and resource ('places' etc.), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'compute_routes' or 'lookup_weather', though the domain distinction is implicit.
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 explicit guidance on when to use this tool: 'when the user's request is to find places, businesses, addresses, locations, points of interest, or any other Google Maps related search.' It includes detailed instructions on location handling and parameter usage, such as when to use 'location_bias' and how to construct queries, though it doesn't mention alternatives since siblings are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!