Google Maps
Server Details
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.
- 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 5 of 5 tools scored.
Each tool has a clearly distinct purpose: routing, weather, URL resolution, name resolution, and place search. Even the resolution tools are differentiated by input type (URLs vs. textual queries). No significant overlap.
All tool names follow a consistent verb_noun pattern with underscores (compute_routes, lookup_weather, resolve_maps_urls, resolve_names, search_places). No mixing of conventions.
Five tools is well-scoped for a maps service, covering essential functionalities without being too few or too many. Each tool adds distinct value.
The tool set covers routing, weather, and place location/resolution. However, missing a dedicated tool to retrieve detailed place information (e.g., hours, reviews) given a place ID, which is a minor gap.
Available Tools
5 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?
Annotations declare readOnlyHint=true, which matches the read-only nature. Description adds behavioral details: WALK routes are beta and may lack sidewalks, output must use attribution field. No contradiction.
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?
Well-organized with bold headings and bullet points. Front-loaded with purpose. Slightly long but every sentence adds value.
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?
Covers input requirements thoroughly, attribution, and beta warning. Output schema exists, so return values need not be explained. No glaring gaps given 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 coverage is 100%, but description adds clarity on input methods (address, lat_lng, place_id) and allowed combinations, plus an example. This goes beyond the 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 states 'Computes a travel route between a specified origin and destination' with a clear verb and resource. It distinguishes itself from sibling tools (weather, URL resolution, name resolution, place search) by focusing on route computation.
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 explicit input requirements and methods (address, lat_lng, place_id) with examples. States that missing origin/destination requires asking user. Mentions WALK mode beta status and display warning. Does not explicitly contrast with alternatives, but siblings are dissimilar.
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?
Annotations declare readOnlyHint=true, and the description reinforces that it retrieves data without modification. It adds significant behavioral context beyond annotations, such as the types of data returned, timezone handling, date constraints, and attribution requirements. This helps the agent understand what the tool does beyond its safety profile.
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 long but well-organized with clear sections and front-loaded purpose. Every sentence serves a purpose (details, rules, examples). Minor redundancy could be trimmed, but overall structure aids readability for an AI agent.
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 4 parameters and an output schema, the description covers all necessary aspects: what data is returned, how to specify location, parameter constraints, timezone handling, and attribution. It addresses potential edge cases (e.g., postal codes need country, hourly forecast beyond 120 hours unsupported) and explains each usage mode thoroughly.
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 substantial value by clarifying the oneof structure for location, providing examples for each location sub-field, and explaining the interplay between date and hour for different usage modes. The description transforms the raw schema into actionable guidance, making it easy for an agent to correctly construct requests.
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 'Retrieves comprehensive weather data including current conditions, hourly, and daily forecasts.' This is a specific verb-resource combination that distinguishes the tool from its siblings (e.g., compute_routes, search_places), which are unrelated.
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 outlines three usage modes (current, hourly, daily) with required parameters and constraints. It explains when to use each mode and provides rules for location selection (oneof structure). While it does not explicitly state when not to use this tool, the context with unrelated siblings makes the guidance clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_maps_urlsARead-onlyInspect
Resolves a list of Google Maps URLs into canonical Google Maps Place IDs.
When to call this tool (CRITICAL):
Use this tool when the user provides one or more Google Maps sharing links or URLs (e.g. 'https://maps.app.goo.gl/...', 'https://www.google.com/maps/place/...', or 'https://maps.google.com/...') and you need to extract the underlying canonical Place IDs.
You can specify up to 20 URLs to resolve in a single batch request.
Input Requirements (CRITICAL):
urls(array of strings - MANDATORY): The list of Google Maps URLs to resolve. Each URL must be a valid, single-place Google Maps URL.
Error Handling (CRITICAL):
This is a batch processing tool. A request might return "mixed results" (e.g. some URLs resolve successfully while others fail).
The output list of
entitiesis guaranteed to map 1:1 with the inputurlsindices. A failed URL resolution will result in an emptyEntitymessage (no fields are set) at its corresponding index in theentitieslist.You MUST check the
failed_requestsmap field in the response to identify which specific URL index failed. The key offailed_requestsrepresents the 0-based index of the failed URL in the request. Do not assume the entire batch call failed because of a partial failure.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Required. The Google Maps URLs to be resolved. Each URL should be a valid Google Maps URL, for example, https://maps.app.goo.gl/..., https://www.google.com/maps/place/..., or https://maps.google.com/.... Currently, only URLs pointing to a single place are supported. You may specify up to 20 URLs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| entities | No | Output only. The list of resolved entities from the Google Maps URLs. Guaranteed to map 1:1 with the request `urls` indices. An empty message at index `i` (where no `entity` is set) indicates the resolution failed for that URL. If the resolution failed, please check the `failed_requests` field for the error status. |
| failedRequests | No | Output only. A map communicating partial failures for the Google Maps URLs. The key is the index of the failed request in the `urls` field. The value is the error status detailing why the resolution failed. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by detailing batch processing (up to 20 URLs), 1:1 mapping to response indices, the failed_requests map for partial failures, and how to interpret empty entities. This adds significant context for correct invocation.
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 headings and sections (When to call, Input Requirements, Error Handling). It is appropriately sized for a batch tool, though some redundancy exists (e.g., repeating URL formats). It front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values are documented separately) and the input schema covers 100% of parameters, the description is complete. It covers input requirements, batch behavior, error handling, and response mapping without gaps.
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 has 100% description coverage, so baseline is 3. The description adds meaning by clarifying that URLs must be valid single-place Google Maps URLs of specific formats (e.g., maps.app.goo.gl) and that up to 20 are allowed, reinforcing and extending 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 resolves Google Maps URLs into canonical Place IDs. It uses a specific verb (resolve) and resource (Maps URLs), and distinguishes from siblings like search_places and resolve_names by focusing on URL-to-ID conversion.
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 includes a 'When to call' section that specifies use when users provide Google Maps sharing links/URLs. It implies when not to use (e.g., for searching places), but does not explicitly name alternative tools like search_places or resolve_names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_namesARead-onlyInspect
Resolves a batch list of specific location queries (landmark names or exact addresses) into canonical Google Maps Place IDs.
Input Requirements (CRITICAL):
queries(array of objects - MANDATORY): A list of location queries to resolve. You may specify up to 20 queries.Each query object must have:
text(string - MANDATORY): The text query representing a specific place name or address to resolve.Examples:
'Googleplex, Mountain View, CA','1600 Amphitheatre Pkwy, Mountain View, CA','Eiffel Tower, Paris'.
location_bias(object - OPTIONAL): Use this to prioritize results near a specific geographic area.Format:
{"viewport": {"low": {"latitude": [value], "longitude": [value]}, "high": {"latitude": [value], "longitude": [value]}}}
region_code(string - OPTIONAL): The Unicode CLDR region code (two-letter country code, e.g.,US,CA) of the user to bias the results.
Instructions for Tool Call:
Specificity (CRITICAL): Queries must represent a specific place name or address. General searches like
'restaurants'or chain names like'Starbucks'are not supported.Do NOT call this tool if the downstream tools you plan to invoke already accept raw address or place name strings directly.
Error Handling (CRITICAL):
This is a batch processing tool. A request might return "mixed results" (e.g. some queries resolve successfully while others fail).
The output list of
resultsis guaranteed to map 1:1 with the inputqueriesindices. A failed query will result in an emptyResultmessage (noentityis set) at its corresponding index in theresultslist.You MUST check the
failed_requestsmap field in the response to identify which specific query index failed. The key offailed_requestsrepresents the 0-based index of the failed query in the request. Do not assume the entire batch call failed because of a partial failure.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | Required. A list of location queries to be resolved. You may specify up to 20 queries. | |
| regionCode | No | Optional. An optional region code to bias the resolution results. If specified, the resolution results will be biased towards the entities that are in or near the specified region. This should be a CLDR region code. For example, "US" or "CA". Including `location_bias` or `region_code` often provides better results by narrowing the search space. If both `location_bias` and `region_code` are specified, `location_bias` takes precedence over `region_code`. | |
| locationBias | No | Optional. An optional region to bias the resolution results. If specified, the resolution results will be biased towards the entities that are closer to this region. Including `location_bias` or `region_code` often provides better results by narrowing the search space. If both `location_bias` and `region_code` are specified, `location_bias` takes precedence over `region_code`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | No | Output only. The list of resolved entities from the location queries. Guaranteed to map 1:1 with the request `queries` indices. An empty string at index `i` indicates the resolution failed for that query. If the resolution failed, please check the `failed_requests` field for the error status. |
| failedRequests | No | Output only. A map communicating partial failures. The key is the index of the failed request in the `queries` field. The value is the error status detailing why the resolution failed. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), the description details batch processing behavior, mixed results, failed_requests map, and 1:1 index mapping. This fully discloses the tool's operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings (Input Requirements, Instructions, Error Handling) and front-loaded purpose. It is detailed but not excessively long; each section adds necessary context.
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 (batch, error handling) and existence of output schema, the description covers all necessary aspects: input requirements, optional parameters, usage constraints, and error handling. Nothing missing for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by providing examples for 'text', exact format for 'location_bias' using viewport, and region_code details. It enhances understanding 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 first sentence clearly states the tool resolves location queries into Google Maps Place IDs. It explicitly distinguishes from siblings by specifying it handles specific place names/addresses, not general search, which differentiates it from 'search_places'.
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 explicit when-not-to-use instruction: 'Do NOT call this tool if the downstream tools you plan to invoke already accept raw address or place name strings directly.' Also specifies required specificity of queries, guiding appropriate use.
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 already mark the tool as read-only and non-destructive. The description adds context about result attribution and the need for location specificity. No contradictions. Could mention error handling or rate limits but acceptable.
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?
Well-structured with headings and bullet points. Front-loads the main purpose. Some repetition and length, but each section provides important guidance. Could be slightly more concise, but overall effective.
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 output schema present, return values need not be explained. Covers all inputs thoroughly, including critical usage instructions. Could address default language or region handling, but sufficient for 4 parameters and complex requirements.
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?
Input schema has 100% coverage, so baseline is 3. The description adds extensive examples, formatting details, and context for text_query (e.g., including attributes like opening hours) and location_bias (how to omit radius). Adds significant value beyond 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 identifies the tool as for finding places, businesses, addresses, and Google Maps searches. It distinguishes from sibling tools like compute_routes and lookup_weather by specifying the domain.
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 when to call the tool ('when the user's request is to find places') and gives detailed instructions on handling ambiguous locations, using location_bias, and providing specific queries. Implicitly excludes routing and weather tasks.
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!