Skip to main content
Glama
tomtom-international

TomTom MCP Server

Official
by tomtom-international
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

TomTom POI Search

tomtom-poi-search
Read-onlyIdempotent

Find businesses by category or name near a location. Filter results by radius, brands, and attributes to locate specific points of interest.

Instructions

Find specific business categories

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
extNoExtended parameters for the search
latNoLatitude for location context. STRONGLY recommended for relevant local results.
lonNoLongitude for location context. Must be used with lat parameter.
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
queryYesName of the POI to search for. If the intended query is a POI category like 'restaurant', provide an empty string for this param and use the category filter parameter to apply the desired category filter.
radiusNoSearch radius in meters. Essential for focused local results. Examples: 1000 (walking), 5000 (driving), 20000 (wide area).
fuelSetNoFuel types: 'Petrol', 'Diesel', 'LPG', 'Hydrogen', 'E85'
topLeftNoTop-left coordinates of bounding box (format: 'lat,lon'). Must be used with btmRight
brandSetNoFilter by brand names. Examples: 'Starbucks,Peet\'s', 'Marriott,Hilton'. Use quotes for brands with commas.
btmRightNoBottom-right coordinates of bounding box (format: 'lat,lon'). Must be used with topLeft
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
typeaheadNoAutocomplete mode for partial queries. Use for search interfaces.
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. Changed7 schema fields changedv1.6.8
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / categorySet / description
      Previous value: -"Filter by POI categories. Common IDs: '7315' (restaurants), '7309' (gas), '7311' (hotels), '9663' (EV charging)."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"
    • changedInput schema / properties / query / description
      Previous value: -"Specific POI category search. Best for finding types of businesses: 'restaurants', 'gas stations', 'hotels', 'parking', 'ATMs', 'hospitals'"New value: +"Name of the POI to search for. If the intended query is a POI category like 'restaurant', provide an empty string for this param and use the category filter parameter to apply the desired category filter."
    • 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 / roadUse
      Removed value: -{
-  "description": "Include road usage information",
-  "type": "boolean"
-}
    • removedInput schema / properties / sort
      Removed value: -{
-  "description": "Sort options for results",
-  "type": "string"
-}
  2. First observedv1.0.0

TDQS

C2.1/5.0
Behavior2/5

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

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) already disclose the safety profile. The description adds no extra context about response format, pagination, rate limits, or the nature of the search. It is not contradictory, but it contributes nothing beyond the annotations.

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 a single vague sentence. While concise, it is under-specified and does not earn its place because it conveys almost no actionable information. It is not structured to front-load critical details, as it lacks any.

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

Completeness1/5

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

For a tool with 34 parameters, many optional, and no output schema, this description is grossly inadequate. It fails to explain what the tool searches, what inputs are essential (e.g., query or location), or how it differs from similar tools. An agent would struggle to call this tool correctly based on the description alone.

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 coverage is 100% with rich parameter descriptions. The description itself adds no parameter-level insight, but the baseline of 3 applies when the schema carries the full burden. No improvement or degradation is warranted.

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

Purpose2/5

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

The description 'Find specific business categories' is vague and does not specify the resource (POIs) or the scope of the search. It fails to differentiate from siblings like tomtom-fuzzy-search or tomtom-nearby, which also search for places. It is not a tautology but lacks the specificity needed to understand what the tool actually does.

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 such as fuzzy search or nearby. It does not mention prerequisites, typical use cases, or exclusions. An agent must infer usage from the name and parameter schema alone, which is insufficient.

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