TomTom MCP Server

Official

by tomtom-international

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

TomTom Waypoint Routing

tomtom-waypoint-routing

Read-onlyIdempotent

Plan multi-stop routes with three or more waypoints, returning optimized turn-by-turn directions, distance, and travel time. Solves sequencing multiple locations in a single journey.

Instructions

Plan multi-stop routes through 3 or more waypoints. Use when the user needs to visit multiple locations in sequence (e.g. 'route from A to B via C and D'). Returns optimized turn-by-turn directions, total distance, and travel time. For simple A-to-B routes, use tomtom-routing instead.

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).
`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).
`waypoints`	Yes	Ordered array of waypoint coordinates (minimum 2). Route calculated in exact sequence provided. Use geocoding for accurate coordinates.
`travelMode`	No	Transportation mode. Default: 'car'.
`sectionType`	No	Road section types to highlight for route analysis. Options: toll (toll roads), motorway (highways), tunnel, urban (city areas), country (rural areas), pedestrian (walking paths), traffic (traffic incidents), toll_road, ferry, travel_mode, important_road_stretch. Accepts array of string(s).
`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.

Changed3 schema fields changedv1.6.8Sep 15, 2026

removedInput schema / 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"
+}

removedInput schema / properties / waypoints / items / additionalProperties
```
Removed value: -false
```

First observedv1.0.0Aug 15, 2025

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it 'returns optimized turn-by-turn directions, total distance, and travel time,' which is useful. However, there is a minor inconsistency: the description says '3 or more waypoints' while the schema allows minItems=2, which could mislead an agent. No contradiction with annotations, but the added behavioral context is modest.

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?

Three sentences with no filler. The primary use case and the key differentiator are front-loaded, and the alternative is named concisely. Every word earns its place.

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 complex tool with 49 parameters, the description adequately covers the core use case and return fields, while the schema handles parameter specifics. It does not mention ordered waypoints or the computeBestOrder option, but those are in the schema. Given annotations and rich schema, nothing critical is missing for an agent to call it correctly.

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 49 parameters in detail. The description only mentions 'waypoints' generically and does not add syntax, ordering, or constraint nuances beyond what the schema provides. Baseline 3 is appropriate since schema does the heavy lifting.

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: 'Plan multi-stop routes through 3 or more waypoints.' It clearly distinguishes itself from the sibling 'tomtom-routing' by specifying the multi-stop scenario, so an agent can tell them apart without opening the schema.

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?

It explicitly says 'Use when the user needs to visit multiple locations in sequence' and directs to 'tomtom-routing' for simple A-to-B routes. This gives clear when-to-use and when-not-to-use guidance, naming the alternative tool.

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

Deploy Server

TomTom Waypoint Routing

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools