Skip to main content
Glama
Sign In

Google Maps

by com.googleapis.mapstools
OverviewDiscussionsAdmin

search_along_route

Read-only

Call this tool when the user wants to find places, businesses, or points of interest along a travel route (e.g., "gas stations on my way to Tahoe", "coffee shops between SF and San Jose"). Calling this tool incurs higher cost than search_places, so use search_places instead when searching near a single location rather than along a route.

Input Requirements (CRITICAL):

  1. text_query (string - MANDATORY): A natural language description of what to search for along the route.

    • Examples: 'ev chargers', 'coffee', 'vegetarian restaurants', 'rest stops'.

  2. Route specification (MANDATORY - provide exactly ONE of the following):

    • retrieval_token (string): The retrieval_token returned by a prior compute_routes call for a DRIVE route. Prefer this whenever the route was already computed. The token is valid for 10 minutes.

    • route_endpoints (object): The route's origin and destination. Each must be provided using one of address, lat_lng, or place_id.

      • Example: {"route_endpoints": {"origin": {"address": "San Francisco, CA"}, "destination": {"address": "Lake Tahoe, CA"}}}

    • encoded_polyline (string): An encoded polyline representing a DRIVE route.

  3. travel_mode (enum - OPTIONAL): DRIVE (default), WALK, or BICYCLE. WALK and BICYCLE are only supported with route_endpoints. TRANSIT is not supported.

  4. routing_preference (enum - OPTIONAL):

    • ROUTING_PREFERENCE_TRAFFIC_UNAWARE (default): computes the route and detours without live traffic. Lowest latency.

    • ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL: uses live traffic conditions when available. Not supported for WALK or BICYCLE. Set this ONLY when the user asks about traffic, congestion, or traffic-adjusted detour times. It incurs higher latency.

  5. include_extended_details (boolean - OPTIONAL): Set to true only when the request requires qualitative review insights, specific menu items or offerings, atmosphere, visitor tips or busyness, EV charger availability, gas prices, or other rich qualitative details. Defaults to false. Enabling it may increase latency.

  6. language_code (string - OPTIONAL): The language for the results summary and place details, e.g., en, ja, en-US. Defaults to en-US.

  7. region_code (string - OPTIONAL): The Unicode CLDR region code of the user, e.g., US, CA.

Instructions for Tool Call:

  • Each result includes a detour_summary (when available) describing the extra distance (localized_detour_distance) and, unless the route was given as encoded_polyline, the extra time (detour_duration) incurred by stopping at that place. Use it to compare options.

  • The response summary may contain zero-based citations (e.g., "[0]") referencing entries in results.

  • The grounded output must be attributed to the source using the attribution field of each results[].place when available.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "textQuery": "<textQuery>"
    },
    "name": "search_along_route"
  }
}

Input Schema

NameRequiredDescriptionDefault
textQueryYesRequired. Natural language search query (e.g., "ev chargers", "coffee").
regionCodeNoOptional. Country/region code (CLDR) of location (e.g., "US").
travelModeNoOptional. Specifies the travel mode used to compute the route and the detours. Defaults to `DRIVE`. `WALK` and `BICYCLE` are only supported with `route_endpoints`. `TRANSIT` is not supported.
languageCodeNoOptional. The language for summary and place details. Defaults to "en-US".
retrievalTokenNoA retrieval token returned from a prior ComputeRoutes call representing the route. Only one of the following fields should be set: this field, encodedPolyline, routeEndpoints.
routeEndpointsNoExplicit route endpoints (origin and destination). Only one of the following fields should be set: this field, encodedPolyline, retrievalToken.
encodedPolylineNoAn encoded polyline string representing the route. See https://developers.google.com/maps/documentation/utilities/polylinealgorithm. Only one of the following fields should be set: this field, retrievalToken, routeEndpoints.
routingPreferenceNoOptional. Optional routing preference specifying how traffic data is used. Defaults to TRAFFIC_UNAWARE.
includeExtendedDetailsNoOptional. Includes extended place details in the response. Set this field to `true` when the user request requires rich qualitative insights, real-time dynamics, or specialized entity attributes: - Qualitative reviews, customer sentiment, and feedback. - Specific offerings like menu items, dishes, food specialties, beverages, or business highlights. - Qualitative atmosphere, interior decor, aesthetic, ambience, or mood. - Real-time data and specialized facility specs, visitor policies/tips, wait times. Leave `false` (default) for standard discovery searches (e.g., cuisines, store types), location/address lookups, contact info, operating hours, and standard metadata/amenities. Enabling this field may incur higher latency.

Output Schema

NameRequiredDescriptionDefault
resultsNoOutput only. The ranked list of search results found along the route.
summaryNoOutput only. Natural language summary of search results and detour trade-offs. May contain zero-based citations (e.g. "[0]", "[1]") referencing the corresponding entries in the `results` list.
contentTokenNoOutput only. An encrypted token that encapsulates the search context and can be passed to Google Maps visual rendering services, SDKs, or the Maps Agentic UI Toolkit (A2UI) to display interactive UI components for the returned search results.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / routingPreference / x-google-enum-descriptions
      Previous value: -[
-  "No routing preference specified. Defaults to `ROUTING_PREFERENCE_TRAFFIC_UNAWARE`.",
-  "Computes routes without taking live traffic conditions into consideration. Suitable when traffic conditions don't matter or are not applicable. Using this value produces the lowest latency.",
-  "Calculates routes taking live traffic conditions into consideration, when traffic data is available. For `TRANSIT`, uses realtime transit data, such as delays and cancellations, when available. This value will trigger the Pro tier and incur higher billing cost and latency. This is only available for allowlisted customers. If not allowlisted, the request will fall back to `ROUTING_PREFERENCE_TRAFFIC_UNAWARE`."
-]New value: +[
+  "No routing preference specified. Defaults to `ROUTING_PREFERENCE_TRAFFIC_UNAWARE`.",
+  "Computes routes without taking live traffic conditions into consideration. Suitable when traffic conditions don't matter or are not applicable. Using this value produces the lowest latency.",
+  "Calculates routes taking live traffic conditions into consideration, when traffic data is available. For `TRANSIT`, uses realtime transit data, such as delays and cancellations, when available. This value will trigger the Pro tier and incur higher billing cost and latency."
+]
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/non-destructive annotations, it discloses cost tiering versus search_places, latency implications of both routing_preference and include_extended_details, the 10-minute validity window on retrieval_token, and that detour_duration is unavailable when a polyline is supplied. It also describes output affordances (detour_summary, zero-based citations, required attribution) that matter operationally.

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?

The critical routing-and-cost sentence is front-loaded and the numbered sections make the constraint ordering easy to scan. It is longer than necessary, however, because items 3-7 largely duplicate schema descriptions already at 100% coverage, and the closing 'Instructions for Tool Call' bullets mix in output/attribution advice.

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?

For a 9-parameter tool with nested route endpoints, enums, and an output schema, nothing essential is missing: mutual exclusion of route specifications, unsupported modes, token expiry, and cost tradeoffs are all covered, and return values are left to the output schema while still explaining how to use them.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real decision semantics: the exactly-one-of rule across retrieval_token/route_endpoints/encoded_polyline with a preference order, and explicit triggers for routing_preference and includeExtendedDetails. Minor deduction because it restates most parameter text verbatim and uses snake_case names (text_query, lat_lng, place_id) that do not match the schema's camelCase keys (textQuery, latLng, placeId), which could cause a mis-keyed call.

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?

Opens with a specific verb and resource ('find places, businesses, or points of interest along a travel route') plus concrete example queries. It explicitly distinguishes itself from the sibling search_places, so an agent can route between the two 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.

Usage Guidelines5/5

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

States when to call it, when NOT to call it ('use `search_places` instead when searching near a single location rather than along a route'), and why (higher cost). Per-parameter guidance also encodes conditional rules, e.g. prefer retrieval_token when a route was already computed, and set routing_preference only when the user asks about traffic.

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

All Google Maps toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources