Skip to main content
Glama

resolve_names

Read-only

Resolves a batch list of specific location queries (landmark names or exact addresses) into canonical Google Maps Place IDs.

Input Requirements (CRITICAL):

  1. 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'.

  2. 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]}}}

  3. 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 results is guaranteed to map 1:1 with the input queries indices. A failed query will result in an empty Result message (no entity is set) at its corresponding index in the results list.

  • You MUST check the failed_requests map field in the response to identify which specific query index failed. The key of failed_requests represents the 0-based index of the failed query in the request. Do not assume the entire batch call failed because of a partial failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queriesYesRequired. A list of location queries to be resolved. You may specify up to 20 queries.
regionCodeNoOptional. 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`.
locationBiasNoOptional. 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

TableJSON Schema
NameRequiredDescriptionDefault
resultsNoOutput 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.
failedRequestsNoOutput 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.

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint=true), description discloses batch processing may return mixed results, results map 1:1 with input indices, and failed_requests identifies specific failed queries. It also notes location_bias precedence over region_code. This is substantial behavioral context not derivable from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is long but well-structured with clear sections (Input Requirements, Instructions, Error Handling) and front-loaded purpose. Each section adds operational value, though some content echoes the schema. Appropriate for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description sufficiently covers purpose, parameter semantics, limitations, and crucial error behavior (partial failures, failed_requests mapping). It also includes exclusions and alternatives (do not call if downstream accepts raw strings). No significant gaps for a batch resolution tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema carries the parameter details. The description repeats the parameter information with examples and formatting, but adds little genuinely new meaning beyond what the schema already provides (e.g., examples of location queries and bias format are present in schema descriptions).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states it resolves a batch list of specific location queries into canonical Google Maps Place IDs, using a specific verb and resource. It distinguishes itself from siblings like search_places by emphasizing 'specific' and 'batch' and even includes a warning not to call if downstream tools accept raw strings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage guidelines: queries must be specific place names/addresses, general searches are unsupported, and it warns against calling when downstream tools accept raw strings. Also explains batch error handling and the need to inspect failed_requests, giving clear when-to-use and when-not-to-use context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Tools are mostly distinct: routing, weather, URL resolution, name resolution, and place search. The main overlap is between resolve_names and search_places, which both handle place lookups but with different purposes (batch exact resolution vs. general search). Still, the descriptions clarify the distinction well.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: compute_routes, lookup_weather, resolve_maps_urls, resolve_names, search_places. Even though verbs vary, the pattern is uniform and predictable.

Tool Count5/5

Five tools is a well-scoped set for a geo/maps server. Each tool has a clear role and covers the core capabilities without bloat. This is within the ideal range.

Completeness4/5

The server covers routing, weather, and multiple place-resolution paths (URLs, names, free-text search). Minor gaps exist, such as no multi-waypoint routing or a dedicated place-details endpoint, but the existing tools can handle most workflows through search_places. Overall surface is solid.

Resources