TomTom MCP Server

Official

by tomtom-international

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

TomTom Reachable Range

tomtom-reachable-range

Read-onlyIdempotent

Determine the reachable area from a starting point within a specified time, distance, or fuel budget, considering traffic, route type, and vehicle restrictions.

Instructions

Determine the area reachable within a specified time or driving distance

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 for reachable area calculation. Typically current location or point of interest.
`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 reachable area calculation.
`departAt`	No	Departure time in ISO format (e.g., '2025-06-24T14:30:00Z').
`hilliness`	No	Preference for avoiding hills. Use 'low' for flatter routes. This can be only used when `routeType` parameter is set to `thrilling`.
`routeType`	No	Route optimization: 'fastest' (time-optimized), 'shortest' (distance-optimized), 'eco' (fuel-efficient).
`travelMode`	No	Travel mode affects reachable area shape. Default: 'car'. Note: Pedestrian/bicycle modes not supported by API.
`windingness`	No	Preference for avoiding winding roads. Use 'low' for straighter routes. This can be only used when `routeType` parameter is set to `thrilling`.
`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.
`response_detail`	No	Response detail level. 'compact' (default): returns center point only, boundary coordinates are trimmed — the MCP App still renders the full reachable range polygon. 'full': includes boundary coordinates in the response, use this when you need to plot or process the boundary data yourself.	compact
`timeBudgetInSec`	No	Maximum travel time in seconds. Examples: 900 (15min), 1800 (30min), 3600 (1h). Use ONLY ONE budget parameter — do not combine with other budget types.
`vehicleLoadType`	No	Cargo type for hazardous materials routing.
`vehicleMaxSpeed`	No	Maximum vehicle speed in km/h for commercial routing.
`uphillEfficiency`	No	Efficiency during uphill driving (0-1).
`energyBudgetInkWh`	No	Maximum energy budget in kWh for electric vehicles. Example: 10 (10 kWh). REQUIRED companions: vehicleEngineType='electric', constantSpeedConsumptionInkWhPerHundredkm, currentChargeInkWh, maxChargeInkWh. Use ONLY ONE budget parameter — do not combine with other budget types.
`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).
`fuelBudgetInLiters`	No	Maximum fuel budget in liters for combustion vehicles. Example: 5 (5 liters). REQUIRED companions: vehicleEngineType='combustion' and constantSpeedConsumptionInLitersPerHundredkm (e.g. '50,6.5:130,11.5'). Use ONLY ONE budget parameter — do not combine with other budget types.
`currentFuelInLiters`	No	Current fuel level in liters for combustion vehicles.
`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).
`distanceBudgetInMeters`	No	Maximum travel distance in meters. Examples: 5000 (5km), 10000 (10km), 20000 (20km). Use ONLY ONE budget parameter — do not combine with other budget types.
`maxFerryLengthInMeters`	No	Maximum allowed ferry length in meters.
`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.

Changed7 schema fields changedv1.6.8Sep 15, 2026

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

changedInput schema / properties / distanceBudgetInMeters / description

Previous value: -"Maximum travel distance in meters. Examples: 5000 (5km), 10000 (10km), 20000 (20km). Either time or distance budget required."New value: +"Maximum travel distance in meters. Examples: 5000 (5km), 10000 (10km), 20000 (20km). Use ONLY ONE budget parameter — do not combine with other budget types."

changedInput schema / properties / energyBudgetInkWh / description

Previous value: -"Maximum energy budget in kWh for electric vehicles. Example: 10 (10 kWh)."New value: +"Maximum energy budget in kWh for electric vehicles. Example: 10 (10 kWh). REQUIRED companions: vehicleEngineType='electric', constantSpeedConsumptionInkWhPerHundredkm, currentChargeInkWh, maxChargeInkWh. Use ONLY ONE budget parameter — do not combine with other budget types."

changedInput schema / properties / fuelBudgetInLiters / description

Previous value: -"Maximum fuel budget in liters for combustion vehicles. Example: 5 (5 liters)."New value: +"Maximum fuel budget in liters for combustion vehicles. Example: 5 (5 liters). REQUIRED companions: vehicleEngineType='combustion' and constantSpeedConsumptionInLitersPerHundredkm (e.g. '50,6.5:130,11.5'). Use ONLY ONE budget parameter — do not combine with other budget types."

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

addedInput schema / properties / response_detail

Added value: +{
+  "default": "compact",
+  "description": "Response detail level. 'compact' (default): returns center point only, boundary coordinates are trimmed — the MCP App still renders the full reachable range polygon. 'full': includes boundary coordinates in the response, use this when you need to plot or process the boundary data yourself.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}

changedInput schema / properties / timeBudgetInSec / description

Previous value: -"Maximum travel time in seconds. Examples: 900 (15min), 1800 (30min), 3600 (1h). Either time or distance budget required."New value: +"Maximum travel time in seconds. Examples: 900 (15min), 1800 (30min), 3600 (1h). Use ONLY ONE budget parameter — do not combine with other budget types."

First observedv1.0.0Aug 15, 2025

TDQS

B3.2/5.0

Behavior3/5

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

Annotations are rich (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description 'determine the area reachable' is consistent with a read-only operation and doesn't contradict the annotations. However, it adds essentially no behavioral context beyond what the annotations already declare — no mention of response format, boundaries, or calculation characteristics.

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 no wasted words — efficient and to the point. It's appropriately terse for a tool whose schema carries all the parameter documentation, though it could arguably add one clause about scope without becoming verbose.

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?

Given the tool's complexity (41 parameters, no output schema), the one-sentence description is minimal. The schema compensates well by documenting every parameter including budget exclusivity and required companions. However, the description doesn't mention that origin is required or that exactly one budget parameter must be supplied — important usage constraints an agent would benefit from knowing up front.

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% and the schema itself documents all 41 parameters thoroughly, including critical constraints like 'Use ONLY ONE budget parameter — do not combine with other budget types' and 'REQUIRED companions' for energy/fuel budgets. With full schema coverage, baseline 3 applies and the description correctly adds no redundant param info.

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?

The description 'Determine the area reachable within a specified time or driving distance' states a specific verb (determine) and resource (area reachable), clearly conveying the isochrone/reachability concept. However, it doesn't differentiate itself from routing siblings like tomtom-routing or tomtom-waypoint-routing, which could also involve travel time/distance — so it's clear but not distinct.

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?

No guidance on when to use this tool versus alternatives. It never mentions that this is for area-based reachability (isochrones) rather than point-to-point routing, nor names any sibling as an alternative. The 'specified time or driving distance' phrasing could even confuse an agent into choosing this over tomtom-routing.

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

Deploy Server

TomTom Reachable Range

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools