TomTom MCP Server

Official

by tomtom-international

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

TomTom Reverse Geocode

tomtom-reverse-geocode

Read-onlyIdempotent

Convert latitude and longitude coordinates into readable street addresses. Retrieve municipality, postal, and address details to support geolocation workflows.

Instructions

Convert coordinates to addresses

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lat`	Yes	Latitude coordinate (-90 to +90). Precision to 4+ decimal places recommended.
`lon`	Yes	Longitude coordinate (-180 to +180). Precision to 4+ decimal places recommended.
`ofs`	No	Offset for pagination of results
`view`	No	Geopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN'
`limit`	No	Maximum number of results to return (1-100). Default: 5
`radius`	No	Search radius in meters. Default: 100
`heading`	No	Heading direction in degrees (0-360) for improved accuracy on roads
`roadUse`	No	Types of road use to include in the results. Examples: 'Arterial', 'Ferry', 'Highway', etc.
`language`	No	Preferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES'
`mapcodes`	No	Include 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).
`timeZone`	No	Used 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
`countrySet`	No	Limit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US'
`geometries`	No	Include geometries information in the response
`maxResults`	No	Maximum results to return (alias for limit)
`addressRanges`	No	Include address ranges in the response
`entityTypeSet`	No	Filter 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
`returnCommune`	No	Include commune information in the results
`returnRoadUse`	No	Include road use types for street level results
`response_detail`	No	Response detail level. 'compact' (default): trimmed response with essential fields only, saves tokens. 'full': complete API response with all fields including coordinates, classifications, etc.	compact
`returnMatchType`	No	Include information about the type of geocoding match achieved
`returnSpeedLimit`	No	Include posted speed limit for street results
`returnAddressNames`	No	Include address names in the response
`allowFreeformNewLine`	No	Allow newlines in freeform addresses
`extendedPostalCodesFor`	No	Include extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI'
`returnRoadAccessibility`	No	Include road accessibility information

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.6.8Sep 15, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / entityTypeSet / description

Previous value: -"Filter by entity types: 'Country', 'Municipality', etc."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"
+}

First observedv1.0.0Aug 15, 2025

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context, but it also does not contradict 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.

Conciseness4/5

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

The description is extremely concise and front-loaded with the main action. There is no redundant wording, though for a tool with 25 parameters a bit more orienting context could still be useful.

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

Completeness3/5

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

The core input (coordinates) and output (addresses) are established, which supports a basic successful invocation. However, with no output schema and 25 optional parameters, the description lacks guidance on defaults, result shape, and optional response controls.

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% across all 25 parameters, so the schema already provides detailed parameter semantics. The description adds no parameter-specific meaning beyond the generic phrase 'coordinates'.

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?

The description names a specific transformation—'Convert coordinates to addresses'—so the tool's purpose is unambiguous. The direction (coordinates → addresses) clearly distinguishes it from sibling tomtom-geocode and other search tools.

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

Usage Guidelines3/5

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

The usage context is implied: use this when you have latitude/longitude and want an address. However, the description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.

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

Deploy Server

TomTom Reverse Geocode

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools