Skip to main content
Glama
tomtom-international

TomTom MCP Server

Official
by tomtom-international
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

TomTom Nearby Search

tomtom-nearby
Read-onlyIdempotent

Find nearby services and points of interest around any location. Specify coordinates, radius, and filters to discover restaurants, gas stations, hotels, and more.

Instructions

Discover services within a radius

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
extNoExtended parameters for the search
latYesCenter latitude for nearby search. Use precise coordinates from geocoding.
lonYesCenter longitude for nearby search. Use precise coordinates from geocoding.
ofsNoOffset for pagination of results
viewNoGeopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN'
limitNoMaximum number of results to return (1-100). Default: 5
radiusNoSearch radius in meters. Default: 1000. Recommended: 500 (walking), 1000 (local), 5000 (driving), 20000 (wide area).
fuelSetNoFuel types: 'Petrol', 'Diesel', 'LPG', 'Hydrogen', 'E85'
roadUseNoInclude road usage information
brandSetNoFilter by brand names. Examples: 'Starbucks,Peet\'s', 'Marriott,Hilton'. Use quotes for brands with commas.
languageNoPreferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES'
mapcodesNoInclude mapcode information in the response. Mapcodes represent specific locations within a few meters and are designed to be short, easy to recognize and communicate. Options: Local, International, Alternative. Examples: 'Local' (local mapcode only), 'Local,Alternative' (multiple types). Accepts array of string(s).
timeZoneNoUsed to indicate the mode in which the timeZone object should be returned. Values: iana Mode shows the IANA ID which allows the user to determine the current time zone for the POI. Usage examples: timeZone=iana
countrySetNoLimit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US'
geometriesNoInclude geometries information in the response
maxPowerKWNoMaximum charging power in kW for EV stations
minPowerKWNoMinimum charging power in kW for EV stations
categorySetNoFilter POI per category using category IDs. Examples: '7315' (Restaurant), '9361' (Shop), '7311' (Gas Station), '7321' (Hospital), '7397' (ATM), '7327' (Department Store), '7314' (Hotel/Motel), '9361009' (Convenience Store), '7324' (Post Office), '7383' (Airport), '7380' (Railroad Station), '9942' (Public Transportation Stop), '7313' (Parking Garage), '7369' (Open Parking Area), '7342' (Movie Theater), '9362' (Park & Recreation Area), '7310' (Repair Shop), '9376' (Café/Pub), '9379' (Nightlife), '7318' (Theater), '7317' (Museum), '7312' (Rent-a-Car Facility), '7372' (School), '7322' (Police Station), '7326' (Pharmacy), '9352' (Company), '7376' (Tourist Attraction), '7332005' (Supermarkets & Hypermarkets), '7315015' (Fast Food)
relatedPoisNoInclude related points of interest
connectorSetNoEV connector types: 'IEC62196Type2CableAttached', 'Chademo', 'TeslaConnector'
openingHoursNoList of opening hours for a POI (Points of Interest).Value: `nextSevenDays` Mode shows the opening hours for next week, starting with the current day in the local time of the POI. Usage example: openingHours=nextSevenDays
addressRangesNoInclude address ranges in the response
entityTypeSetNoFilter results by geographic entity types. Valid values: PostalCodeArea, CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision, MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality. Note: This parameter is for geographic entities only, not POIs. For POI filtering, use categorySet instead
maxFuzzyLevelNoMaximum fuzzy matching level (1-4)
minFuzzyLevelNoMinimum fuzzy matching level (1-4)
vehicleTypeSetNoA comma-separated list of vehicle types that could be used to restrict the result to the Points Of Interest of specific vehicles. If vehicleTypeSet is specified, the query can remain empty. Only POIs with a proper vehicle type will be returned. Value: A comma-separated list of vehicle type identifiers (in any order). When multiple vehicles types are provided, only POIs that belong to (at least) one of the vehicle types from the provided list will be returned. Available vehicle types: Car , Truck
response_detailNoResponse detail level. 'compact' (default): trimmed response with essential fields only, saves tokens. 'full': complete API response with all fields including coordinates, classifications, etc.compact
fuelAvailabilityNoInclude fuel availability information for gas stations
parkingAvailabilityNoInclude parking availability information
chargingAvailabilityNoInclude charging availability information for EV stations
extendedPostalCodesForNoInclude extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI'

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.6.8
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / categorySet / description
      Previous value: -"POI category filter. Common: '7315' (restaurants), '7309' (gas), '9663' (EV charging), '7311' (hotels), '9376' (parking)."New value: +"Filter POI per category using category IDs.\n      Examples: \n      '7315' (Restaurant), '9361' (Shop), '7311' (Gas Station), '7321' (Hospital),\n      '7397' (ATM), '7327' (Department Store), '7314' (Hotel/Motel), '9361009' (Convenience Store),\n      '7324' (Post Office), '7383' (Airport), '7380' (Railroad Station), '9942' (Public Transportation Stop),\n      '7313' (Parking Garage), '7369' (Open Parking Area), '7342' (Movie Theater),\n      '9362' (Park & Recreation Area), '7310' (Repair Shop), '9376' (Café/Pub), '9379' (Nightlife),\n      '7318' (Theater), '7317' (Museum), '7312' (Rent-a-Car Facility), '7372' (School),\n      '7322' (Police Station), '7326' (Pharmacy), '9352' (Company), '7376' (Tourist Attraction),\n      '7332005' (Supermarkets & Hypermarkets), '7315015' (Fast Food)"
    • changedInput schema / properties / entityTypeSet / description
      Previous value: -"Filter results by entity types"New value: +"Filter results by geographic entity types. Valid values: PostalCodeArea,\n      CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision,\n      MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality.\n      Note: This parameter is for geographic entities only, not POIs.\n      For POI filtering, use categorySet instead"
    • addedInput schema / properties / response_detail
      Added value: +{
+  "default": "compact",
+  "description": "Response detail level. 'compact' (default): trimmed response with essential fields only, saves tokens. 'full': complete API response with all fields including coordinates, classifications, etc.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
    • removedInput schema / properties / sort
      Removed value: -{
-  "description": "Sort options for results",
-  "type": "string"
-}
  2. First observedv1.0.0

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond what annotations and schema provide, such as default radius, response format, or typical usage patterns. It offers no additional disclosure about behavior like pagination, filtering, or data scope, so it adds little value given the existing structured metadata.

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

Conciseness2/5

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

The description is extremely concise—a single sentence—but it is under-specified rather than optimally concise. It does not front-load key information like the fact that it requires lat/lon, uses a radius, or returns POIs. For a tool with 31 parameters, a one-line generic tagline is not adequate structure; it fails to guide the agent toward understanding the tool's purpose without diving deep into the schema.

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

Completeness2/5

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

Given the tool's complexity (31 parameters, 2 required) and the rich schema, the description is far from complete. It does not explain the core use case (finding POIs near a coordinate), how it relates to sibling search tools, or any typical scenarios. The schema is thorough but the description adds no overview or relational context, leaving an agent to puzzle out the tool's role without a high-level map.

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 31 parameters are all individually documented. The tool description does not supplement parameter understanding at all, but since the baseline for high schema coverage is 3, this score is appropriate. The description's single sentence does not clarify any parameter relationships or defaults, but that is not its responsibility given the schema richness.

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

Purpose3/5

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

The description 'Discover services within a radius' conveys a nearby search concept, but it is too generic and does not specify that it operates on a center coordinate and radius, nor does it differentiate from sibling tools like tomtom-poi-search or tomtom-fuzzy-search. The verb 'discover' and resource 'services' are present, but the lack of specificity about the exact resource type (e.g., POIs, charging stations) and the lack of comparison to alternatives make it only minimally clear.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is appropriate when coordinates are known and the user wants nearby results, nor does it explicitly contrast with tomtom-geocode, tomtom-poi-search, or tomtom-fuzzy-search. An agent would have to infer usage solely from the schema, which lacks contextual routing advice.

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