Skip to main content
Glama
Sign In
tomtom-international

TomTom MCP Server

Official
by tomtom-international
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

TomTom Search Along Route

tomtom-search-along-route
Read-onlyIdempotent

Finds points of interest such as restaurants, gas stations, or hotels along a route corridor and returns those within a configurable distance of the calculated route.

Instructions

Find points of interest (restaurants, gas stations, hotels, etc.) along a route corridor. Calculates the route between origin and destination, then searches for POIs within a configurable distance from the route. The route line is omitted unless response_detail is 'geometry'.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of POI results (1-100). Default: 10.
queryYesWhat to search for along the route. Examples: 'gas station', 'restaurant', 'coffee', 'hotel', 'EV charging'.
originYesRoute starting point as [longitude, latitude] (GeoJSON convention). Use precise coordinates from geocoding. Example: [4.89707, 52.377956].
show_uiNoRequest the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false
languageNoLanguage for results (IETF tag). Examples: 'en-US', 'de-DE'.
routeTypeNoRoute optimization for the base route: 'fast', 'short', 'efficient' or 'thrilling'. Default: 'fast'.
destinationYesRoute ending point as [longitude, latitude] (GeoJSON convention). Use precise coordinates from geocoding. Example: [13.404954, 52.520008].
corridorWidthNoSearch corridor width in meters from the route centerline. Default: 5000 (5km). Smaller values = closer to route.
poiCategoriesNoFilter POI results by UPPER_SNAKE_CASE text category codes (e.g. 'RESTAURANT', 'PARKING_GARAGE'), NOT numeric IDs. IMPORTANT: Never guess codes — always call tomtom-poi-categories first with the user's intent as keywords to discover valid codes.
response_detailNoResponse detail level. 'compact' (default): essential fields and point coordinates, no geometry. 'geometry': compact plus a 'geometry' key holding a GeoJSON FeatureCollection ([lon, lat], at most 1,000 vertices per feature); use this to get coordinates to draw or process. 'full': the raw API response, lossless and many times larger.compact

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.13

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already carry readOnly/idempotent/openWorld/destructive=false, so the safety profile is covered. The description adds real behavioral context beyond that: the route line is omitted by default, and response_detail='full' is 'many times larger', which warns about payload size. No statement about rate limits or auth needs, but for a read-only search that is minor.

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

Conciseness5/5

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

Three sentences, front-loaded with the action, then the mechanism, then the output caveat. Nothing redundant; each sentence carries distinct information.

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

Completeness4/5

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

For a 10-parameter, no-output-schema tool, the description plus the fully documented schema cover what an agent needs to invoke it correctly. A small gap remains: it doesn't restate the required geocoded coordinate prerequisite or hint at result ordering/pagination, though the schema covers the coordinate format.

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 baseline is 3. The description earns the extra point by crossing parameter boundaries: it links response_detail='geometry' to the presence of the route line, explaining the practical consequence of an enum choice rather than just restating the schema.

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?

States a specific verb and resource ('Find points of interest... along a route corridor') and immediately explains the mechanism (route between origin and destination, then POI search within a buffer). This clearly distinguishes it from the point-based siblings like tomtom-nearby, tomtom-poi-search, and tomtom-area-search.

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

Usage Guidelines4/5

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

The 'along a route corridor' framing makes the selection condition implicit against point/area search siblings, and the description routes the agent through a prerequisite workflow for categories via tomtom-poi-categories. It stops short of explicitly naming the alternative tools or stating when-not to use this one.

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

Deploy Server

Other Tools