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 longitude/latitude coordinates into human-readable addresses. Specify a position to reverse geocode and filter results by language, entity type, or search radius.

Instructions

Convert coordinates to addresses.

Input Schema

Name	Required	Description	Default
`view`	No	Geopolitical view for disputed territories.
`radius`	No	Search radius in meters. Default: 100
`heading`	No	Heading direction in degrees (0-360) for improved accuracy on roads
`show_ui`	No	Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false
`language`	No	Preferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES'
`position`	Yes	Position as [longitude, latitude] to reverse geocode (GeoJSON convention). Precision to 4+ decimal places recommended. Example: [4.89707, 52.377956].
`entityType`	No	Filter by geography entity types, comma-separated: Country, CountrySubdivision, CountrySecondarySubdivision, CountryTertiarySubdivision, Municipality, MunicipalitySubdivision, MunicipalitySecondarySubdivision, Neighbourhood, PostalCodeArea. Not with heading, which the API then ignores.
`response_detail`	No	Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger.	compact

Schema Changelog

Changes observed during successful MCP inspections.

Changed27 schema fields changedv1.6.13Oct 24, 2026

removedInput schema / properties / addressRanges

Removed value: -{
-  "description": "Include address ranges in the response",
-  "type": "boolean"
-}

removedInput schema / properties / allowFreeformNewLine

Removed value: -{
-  "description": "Allow newlines in freeform addresses",
-  "type": "boolean"
-}

removedInput schema / properties / countrySet

Removed value: -{
-  "description": "Limit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US'",
-  "type": "string"
-}

addedInput schema / properties / entityType

Added value: +{
+  "description": "Filter by geography entity types, comma-separated: Country, CountrySubdivision, CountrySecondarySubdivision, CountryTertiarySubdivision, Municipality, MunicipalitySubdivision, MunicipalitySecondarySubdivision, Neighbourhood, PostalCodeArea. Not with heading, which the API then ignores.",
+  "type": "string"
+}

removedInput schema / properties / entityTypeSet

Removed value: -{
-  "description": "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",
-  "type": "string"
-}

removedInput schema / properties / extendedPostalCodesFor

Removed value: -{
-  "description": "Include extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI'",
-  "type": "string"
-}

removedInput schema / properties / geometries

Removed value: -{
-  "description": "Include geometries information in the response",
-  "type": "boolean"
-}

removedInput schema / properties / lat

Removed value: -{
-  "description": "Latitude coordinate (-90 to +90). Precision to 4+ decimal places recommended.",
-  "type": "number"
-}

removedInput schema / properties / limit

Removed value: -{
-  "description": "Maximum number of results to return (1-100). Default: 5",
-  "maximum": 100,
-  "minimum": 1,
-  "type": "number"
-}

removedInput schema / properties / lon

Removed value: -{
-  "description": "Longitude coordinate (-180 to +180). Precision to 4+ decimal places recommended.",
-  "type": "number"
-}

removedInput schema / properties / mapcodes

Removed value: -{
-  "description": "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).",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

removedInput schema / properties / maxResults

Removed value: -{
-  "description": "Maximum results to return (alias for limit)",
-  "type": "number"
-}

removedInput schema / properties / ofs

Removed value: -{
-  "description": "Offset for pagination of results",
-  "type": "number"
-}

addedInput schema / properties / position

Added value: +{
+  "description": "Position as [longitude, latitude] to reverse geocode (GeoJSON convention). Precision to 4+ decimal places recommended. Example: [4.89707, 52.377956].",
+  "items": {
+    "type": "number"
+  },
+  "maxItems": 2,
+  "minItems": 2,
+  "type": "array"
+}

changedInput schema / properties / response_detail / description

Previous value: -"Response detail level. 'compact' (default): trimmed response with essential fields only, saves tokens. 'full': complete API response with all fields including coordinates, classifications, etc."New value: +"Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger."

removedInput schema / properties / returnAddressNames

Removed value: -{
-  "description": "Include address names in the response",
-  "type": "boolean"
-}

removedInput schema / properties / returnCommune

Removed value: -{
-  "description": "Include commune information in the results",
-  "type": "boolean"
-}

removedInput schema / properties / returnMatchType

Removed value: -{
-  "description": "Include information about the type of geocoding match achieved",
-  "type": "boolean"
-}

removedInput schema / properties / returnRoadAccessibility

Removed value: -{
-  "description": "Include road accessibility information",
-  "type": "boolean"
-}

removedInput schema / properties / returnRoadUse

Removed value: -{
-  "description": "Include road use types for street level results",
-  "type": "boolean"
-}

removedInput schema / properties / returnSpeedLimit

Removed value: -{
-  "description": "Include posted speed limit for street results",
-  "type": "boolean"
-}

removedInput schema / properties / roadUse

Removed value: -{
-  "description": "Types of road use to include in the results. Examples: 'Arterial', 'Ferry', 'Highway', etc.",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

addedInput schema / properties / show_ui

Added value: +{
+  "default": false,
+  "description": "Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false",
+  "type": "boolean"
+}

removedInput schema / properties / timeZone

Removed value: -{
-  "description": "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",
-  "type": "string"
-}

changedInput schema / properties / view / description

Previous value: -"Geopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN'"New value: +"Geopolitical view for disputed territories."

addedInput schema / properties / view / enum

Added value: +[
+  "Unified",
+  "AE",
+  "AR",
+  "BN",
+  "CL",
+  "CN",
+  "DZ",
+  "IL",
+  "IN",
+  "KR",
+  "MA",
+  "MY",
+  "PH",
+  "PK",
+  "RS",
+  "RU",
+  "TR",
+  "TW",
+  "US",
+  "VN"
+]

changedInput schema / required

Previous value: -[
-  "lat",
-  "lon"
-]New value: +[
+  "position"
+]

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

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds no behavioral context beyond that – nothing about the entityType/heading conflict, the interactive widget (show_ui), or response size differences (response_detail), all of which meaningfully change behavior.

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?

A single, front-loaded sentence with zero waste. It is arguably under-specified rather than padded, so it earns high marks on conciseness alone.

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?

For an eight-parameter tool with no output schema, the description is thin, but the rich annotations and fully documented schema compensate for most of the gap. An agent can still call it correctly by reading the schema.

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 all eight parameters, including enums, defaults, and the entityType/heading interaction, are already documented in the schema. The description contributes nothing extra, which is the expected baseline when the schema does the heavy lifting.

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

Purpose4/5

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

States a specific verb ('Convert') and resource ('coordinates to addresses'), which is clear and actionable. It does not explicitly distinguish itself from the inverse sibling tomtom-geocode, so it falls short of a 5.

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?

There is no guidance on when to use this tool versus tomtom-geocode (the reverse direction) or the search tools, and no mention of prerequisites or exclusions. The agent must infer usage entirely from the name.

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