TomTom MCP Server

Official

by tomtom-international

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

TomTom Routing

tomtom-routing

Read-onlyIdempotent

Calculate optimal routes between two locations with turn-by-turn directions, distance, travel time, and map image. Adjust for traffic, departure time, travel mode, route type, and vehicle constraints.

Instructions

Calculate optimal routes between two locations. The primary tool for directions, routes, travel time, or distance between places (e.g. 'route from Amsterdam to Berlin', 'how long to drive from A to B'). Returns turn-by-turn directions, distance, travel time, and a map image. Multi-stop routes with 3+ waypoints are handled by tomtom-waypoint-routing; visualizing multiple routes or combining routes with markers/polygons on a single map image is handled by tomtom-dynamic-map.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`avoid`	No	Route features to avoid. May increase travel time. Options: 'tollRoads','motorways','ferries','unpavedRoads','carpools','alreadyUsedRoads'. Accepts array of string(s).
`origin`	Yes	Starting point coordinates. Obtain from geocoding for best results.
`report`	No	Specifies which data should be reported for diagnostic purposes. A possible value is: `effectiveSettings`. Reports the effective parameters or data used when calling the API. In the case of defaulted parameters, the default will be reflected where the parameter was not specified by the caller. Default value: effectiveSettings
`traffic`	No	Include real-time traffic data for more accurate ETAs and route suggestions.
`arriveAt`	No	Arrival time in ISO format (e.g., '2025-06-24T17:00:00Z'). Cannot be used with departAt.
`departAt`	No	Departure time in ISO format (e.g., '2025-06-24T14:30:00Z'). Cannot be used with arriveAt.
`language`	No	Language code for instructions (e.g., 'en-US', 'de-DE').
`hilliness`	No	Preference for avoiding hills. Use 'low' for flatter routes.
`routeType`	No	Route optimization: 'fastest' (time-optimized), 'shortest' (distance-optimized), 'eco' (fuel-efficient), 'thrilling' (scenic).
`travelMode`	No	Transportation mode. Default: 'car'.
`destination`	Yes	Destination coordinates. Obtain from geocoding for best results.
`sectionType`	No	Highlight specific road section types in response for route analysis: toll (toll roads), motorway (highways), tunnel, urban (city areas), country (rural areas), pedestrian (walking paths), etc.
`windingness`	No	Preference for avoiding winding roads. Use 'low' for straighter routes.
`vehicleWidth`	No	Vehicle width in meters. Used to avoid narrow roads.
`vehicleHeight`	No	Vehicle height in meters. Used to avoid low bridges.
`vehicleLength`	No	Vehicle length in meters. Affects maneuverability restrictions.
`vehicleWeight`	No	Vehicle weight in kg. Important for truck routing restrictions.
`maxChargeInkWh`	No	Maximum EV battery capacity in kWh. Required for EV routing.
`vehicleHeading`	No	Heading of the vehicle in degrees (0-359) for more accurate initial routing.
`alternativeType`	No	When maxAlternatives is greater than 0, it allows the definition of computing alternative routes: finding routes that are significantly different from the reference route, or finding routes that are better than the reference route. Possible values are: `anyRoute` (returns alternative routes that are significantly different from the reference route.), `betterRoute` (only returns alternative routes that are better than the reference route, according to the given planning criteria (set by routeType). If there is a road block on the reference route, then any alternative that does not contain any blockages will be considered a better route. The summary in the route response will contain information (see the planningReason parameter) about the reason for the better alternative.) Note: The betterRoute value can only be used when reconstructing a reference route. Default value: `anyRoute` Other values: `betterRoute`
`maxAlternatives`	No	Number of alternative routes (0-5). More alternatives = more options but larger response.
`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
`vehicleLoadType`	No	Cargo type for hazardous materials routing.
`vehicleMaxSpeed`	No	Maximum vehicle speed in km/h for commercial routing.
`computeBestOrder`	No	Reorder waypoints for optimization. Use with multiple waypoints to find the most efficient route order.
`instructionsType`	No	Instruction format: 'text' (human-readable), 'coded' (machine-readable), 'tagged' (HTML).
`supportingPoints`	No	Additional coordinates that influence the route shape without being stops (format: 'lat,lon;lat,lon').
`uphillEfficiency`	No	Efficiency during uphill driving (0-1).
`vehicleAxleWeight`	No	Vehicle axle weight in kg for weight-restricted roads.
`vehicleCommercial`	No	Commercial vehicle flag. Affects road access restrictions.
`vehicleEngineType`	No	Engine type for fuel/energy consumption calculation.
`auxiliaryPowerInkW`	No	Auxiliary power consumption in kW for electric vehicles.
`chargeMarginsInkWh`	No	Comma-separated charge margins in kWh for route planning.
`currentChargeInkWh`	No	Current EV battery charge in kWh. Required for EV routing.
`downhillEfficiency`	No	Efficiency during downhill driving (0-1).
`currentFuelInLiters`	No	Current fuel level in liters for combustion vehicles.
`routeRepresentation`	No	Representation of routes in response: 'polyline' (default, includes points), 'encodedPolyline' (compressed format), 'summaryOnly' (no points), 'none' (with computeBestOrder only). It cannot be used when `maxAlternatives` is set
`computeTravelTimeFor`	No	Calculate travel times for all segments ('all') or none ('none').
`vehicleNumberOfAxles`	No	Number of axles on the vehicle. Used for toll calculations and restrictions.
`accelerationEfficiency`	No	Efficiency during acceleration (0-1).
`decelerationEfficiency`	No	Efficiency during deceleration (0-1).
`includeTollPaymentTypes`	No	Include toll payment types in the toll section. If a toll section has different toll payment types in its subsections, this toll section is split into multiple toll sections with the toll payment types. Possible values: all(Include toll payment types in the toll section.), none (Do not include toll payment types in the toll section). The value `all` must be used together with sectionType=toll. Default value: none
`extendedRouteRepresentation`	No	Additional routing data formats to include in the response.
`auxiliaryPowerInLitersPerHour`	No	Auxiliary power consumption for combustion vehicles in L/hr.
`vehicleAdrTunnelRestrictionCode`	No	ADR tunnel restriction code for hazardous materials.
`consumptionInkWhPerkmAltitudeGain`	No	Energy used per km of altitude gain.
`fuelEnergyDensityInMJoulesPerLiter`	No	Fuel energy density in megajoules per liter.
`recuperationInkWhPerkmAltitudeLoss`	No	Energy recovered per km of altitude loss.
`constantSpeedConsumptionInkWhPerHundredkm`	No	EV speed-to-consumption mappings format: '50,8.2:130,21.3' (speed in km/h, consumption in kWh/100km).
`constantSpeedConsumptionInLitersPerHundredkm`	No	Combustion speed-to-consumption mappings: '50,6.3:130,11.5' (speed in km/h, consumption in L/100km).

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv1.6.8Sep 15, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / destination / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / destination / properties / lat / $ref
```
Removed value: -"#/properties/origin/properties/lat"
```

addedInput schema / properties / destination / properties / lat / description

Added value: +"Latitude coordinate (-90 to +90). Use precise coordinates from geocoding for best results."

addedInput schema / properties / destination / properties / lat / type
```
Added value: +"number"
```
removedInput schema / properties / destination / properties / lon / $ref
```
Removed value: -"#/properties/origin/properties/lon"
```

addedInput schema / properties / destination / properties / lon / description

Added value: +"Longitude coordinate (-180 to +180). Use precise coordinates from geocoding for best results."

addedInput schema / properties / destination / properties / lon / type
```
Added value: +"number"
```
removedInput schema / properties / origin / additionalProperties
```
Removed value: -false
```

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

A4.3/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond annotations: it returns turn-by-turn directions, distance, travel time, and a map image, which matters because there is no output schema. This is meaningful but not exhaustive given the tool's large parameter space.

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 compact and front-loaded, starting with the core purpose, then use cases and return values, and ending with sibling routing. Every sentence earns its place, and the examples make intent concrete. It is not maximally lean due to some redundancy between 'primary tool for directions/routes' and 'calculate optimal routes,' but it is efficient overall.

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?

For a highly complex 50-parameter tool with no output schema, the description covers the essential selection criteria: what the tool does, what it returns, and when to route to siblings. It does not explicitly instruct the agent to geocode place names into lat/lon coordinates first, though the schema does say this. Overall the description is complete enough for an agent to invoke it correctly for basic and moderate routing requests.

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 baseline is 3; the schema documents all 50 parameters in detail. The description adds little parameter-level meaning, only examples like 'route from Amsterdam to Berlin' that imply place-name inputs even though origin and destination are coordinate objects. It neither contradicts the schema nor substantially enriches it beyond the baseline.

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 states a specific verb and resource: 'Calculate optimal routes between two locations,' and frames it as 'the primary tool for directions, routes, travel time, or distance between places.' It clearly distinguishes itself from tomtom-waypoint-routing and tomtom-dynamic-map, so an agent can separate it from siblings without opening schemas.

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

Usage Guidelines5/5

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

Explicitly names alternative tools and the conditions for using them: 'Multi-stop routes with 3+ waypoints are handled by tomtom-waypoint-routing' and 'visualizing multiple routes or combining routes with markers/polygons on a single map image is handled by tomtom-dynamic-map.' This gives clear when-to-use and when-not-to-use guidance.

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

Deploy Server

TomTom Routing

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools