Skip to main content
Glama
tomtom-international

TomTom MCP Server

Official
by tomtom-international
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

TomTom Geocode

tomtom-geocode
Read-onlyIdempotent

Convert street addresses to geographic coordinates (latitude/longitude) for mapping and location services. Provide full address details like street, city, and country to get accurate results.

Instructions

Convert street addresses to coordinates (does not support points of interest)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoCenter latitude for location bias
lonNoCenter longitude for location bias
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
queryYesFull address to convert to coordinates. Include as much detail as possible (street, city, country) for accurate results. Examples: '1600 Pennsylvania Ave, Washington DC', 'Eiffel Tower, Paris, France'
radiusNoSearch radius in meters when lat/lon provided
topLeftNoTop-left coordinates of bounding box (format: 'lat,lon'). Must be used with btmRight
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
countrySetNoLimit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US'
geometriesNoInclude geometries information in the response
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
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
extendedPostalCodesForNoInclude extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI'

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.6.8
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / entityTypeSet / description
      Previous value: -"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"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"
+}
  2. First observedv1.0.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds one useful behavioral constraint—no POI support—but says nothing about result ambiguity, coordinate format, or response behavior.

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?

The description is a single focused sentence that front-loads the core purpose and includes a meaningful limitation. Every word earns its place, and there is no redundant restating of the tool name or title.

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?

Given the rich 100%-covered schema and clear annotations, the description is mostly complete for safe invocation. The main gap is the lack of explicit routing to sibling tools for POI or fuzzy cases, but the core operation and constraints are sufficiently clear.

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 schema already documents all 17 parameters with examples and constraints. The tool description adds no parameter-level meaning beyond what the schema provides, matching the baseline for full schema coverage.

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 uses a specific verb and resource: 'Convert street addresses to coordinates'. It also adds a distinguishing scope constraint, 'does not support points of interest', which separates it from POI-oriented sibling tools like tomtom-poi-search and tomtom-fuzzy-search.

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 description implies the tool is for address-to-coordinate conversion and explicitly excludes POI lookups. However, it does not name alternatives or give explicit guidance on when to choose this over tomtom-reverse-geocode or tomtom-fuzzy-search.

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