The TomTom MCP Server provides seamless access to TomTom's location services for geospatial development and AI workflows.
Geocoding & Reverse Geocoding: Convert addresses to coordinates and coordinates to human-readable addresses with global coverage
Search & Discovery: Find points of interest using fuzzy search with typo tolerance, category-based POI search, and nearby services within a specified radius
Routing & Navigation: Calculate optimal routes between locations with multiple travel modes (car, pedestrian, bicycle, truck), plan multi-stop routes, and determine reachable areas by time/distance (isochrones)
Traffic Information: Access real-time traffic incident data within defined geographic areas
Map Visualization: Generate custom static map images and create advanced dynamic maps with custom markers, routes, and traffic visualization
Backend Flexibility: Choose between standard Genesis TomTom APIs or advanced Orbis backend (Public Preview) for enhanced features
AI Integration: Easily integrate into AI development environments like Claude Desktop, VS Code, Cursor AI, WindSurf, and Smolagents
Supports configuration through .env files for storing API keys and other configuration options.
Allows users to report issues, contribute code, and access documentation through the GitHub repository.
Runs as a Node.js application, enabling developers to incorporate TomTom's geospatial capabilities into Node.js-based AI workflows.
Provides access to TomTom's location services including geocoding, reverse geocoding, fuzzy search, POI search, nearby search, routing, waypoint routing, reachable range, traffic data, and static maps generation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@TomTom MCP Server find coffee shops near Central Park in New York"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The TomTom Maps MCP Server simplifies geospatial development by providing seamless access to TomTom’s location services, including search, routing, traffic and static maps data. It enables easy integration of precise and accurate geolocation data into AI workflows and development environments.
Related MCP server: mcp-tomtom
Public Preview — The TomTom Maps Remote MCP Server is currently in public preview.
The easiest way to get started is to connect directly to TomTom's hosted MCP Server — no Node.js, Docker, or local setup needed.
Endpoint:
https://mcp.tomtom.com/mapsPrerequisites:
A valid TomTom API key with MCP Server access enabled (see API Key Management)
Add the following to your MCP client configuration:
{
"mcpServers": {
"tomtom-mcp": {
"type": "http",
"url": "https://mcp.tomtom.com/maps",
"headers": {
"tomtom-api-key": "your_api_key_here"
}
}
}
}Add the optional tomtom-maps-backend header to choose your backend:
TomTom Maps (default):
{
"mcpServers": {
"tomtom-mcp": {
"type": "http",
"url": "https://mcp.tomtom.com/maps",
"headers": {
"tomtom-api-key": "your_api_key_here",
"tomtom-maps-backend": "tomtom-maps"
}
}
}
}TomTom Orbis Maps:
{
"mcpServers": {
"tomtom-mcp": {
"type": "http",
"url": "https://mcp.tomtom.com/maps",
"headers": {
"tomtom-api-key": "your_api_key_here",
"tomtom-maps-backend": "tomtom-orbis-maps"
}
}
}
}If the tomtom-maps-backend header is omitted, the server defaults to TomTom Maps.
Create or edit .vscode/mcp.json in your workspace:
{
"servers": {
"tomtom-mcp": {
"type": "http",
"url": "https://mcp.tomtom.com/maps",
"headers": {
"tomtom-api-key": "your_api_key_here"
}
}
}
}The quickest option is to install the pre-built extension — see the Claude Desktop Setup guide for details.
Alternatively, configure Claude Desktop to use the remote server directly by editing your configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"tomtom-mcp": {
"type": "http",
"url": "https://mcp.tomtom.com/maps",
"headers": {
"tomtom-api-key": "your_api_key_here"
}
}
}
}Note: If your MCP client does not support remote HTTP connections with custom headers, use the local setup instead.
Keeping local deployments of the TomTom Maps MCP Server up-to-date is the responsibility of the MCP client/operator. TomTom publishes updates to address known vulnerabilities, but failing to apply updates, patches, or recommended security configurations to your local instance may expose it to known vulnerabilities.
Node.js 22.x
TomTom API key
How to obtain a TomTom API key:
Create a developer account on TomTom Developer Portal and Sign-in
Go to API & SDK Keys in the left-hand menu.
Click the red Create Key button.
Select all available APIs to ensure full access, assign a name to your key, and click Create.
For more details, visit the TomTom API Key Management Documentation.
npm install @tomtom-org/tomtom-mcp@latest
# or run directly without installing
npx @tomtom-org/tomtom-mcp@latestSet your TomTom API key using one of the following methods:
# Option 1: Use a .env file (recommended)
echo "TOMTOM_API_KEY=your_api_key" > .env
# Option 2: Environment variable
export TOMTOM_API_KEY=your_api_key
# Option 3: Pass as CLI argument
TOMTOM_API_KEY=your_api_key npx @tomtom-org/tomtom-mcp@latestVariable | Description | Default |
| Your TomTom API key | - |
| Backend to use: |
|
| Port for the HTTP server |
|
| Logging level: |
|
Stdio Mode (Default - for AI assistants like Claude):
# Start MCP server via stdio
npx @tomtom-org/tomtom-mcp@latestHTTP Mode (for web applications and API integration):
pnpm run build # Build first (required)
pnpm run start:http
# or run the built binary directly
node bin/tomtom-mcp-http.jsWhen running in HTTP mode, you need to include your API key in the tomtom-api-key header. You can also optionally set the maps backend per-request using the tomtom-maps-backend header:
tomtom-api-key: <API_KEY>
tomtom-maps-backend: tomtom-maps # or tomtom-orbis-mapsNote: The
tomtom-maps-backendheader is only used when the server is started without theMAPSenv var (dual-backend mode). IfMAPSis set at startup, the header is ignored and the server uses the fixed backend.
For example, to make a request using curl:
curl --location 'http://localhost:3000/mcp' \
--header 'Accept: application/json,text/event-stream' \
--header 'tomtom-api-key: <API KEY>' \
--header 'Content-Type: application/json' \
--data '{
"method": "tools/call",
"params": {
"name": "tomtom-geocode",
"arguments": {
"query": "Amsterdam Central Station"
}
},
"jsonrpc": "2.0",
"id": 24
}'The Docker setup is also configured to use this HTTP mode with the same authentication method.
Docker Mode (recommended):
# Option 1: Using docker run directly
# Note: TomTom Maps is the default backend (same as npm package)
docker run -p 3000:3000 ghcr.io/tomtom-international/tomtom-maps-mcp:latest
# To use TomTom Orbis Maps backend instead:
docker run -p 3000:3000 -e MAPS=tomtom-orbis-maps ghcr.io/tomtom-international/tomtom-maps-mcp:latest
# Option 2: Using Docker Compose (recommended for development)
# Clone the repository first
git clone https://github.com/tomtom-international/tomtom-maps-mcp.git
cd tomtom-maps-mcp
# Start the service (uses TomTom Maps backend by default)
docker compose upBoth Docker options run the server in HTTP mode. Pass your API key via the tomtom-api-key header as shown in the HTTP Mode curl example above.
TomTom Maps MCP Server can be easily integrated into various AI development environments and tools.
These guides help you integrate the MCP server with your tools and environments:
Claude Desktop Setup - Instructions for configuring Claude Desktop to work with TomTom Maps MCP server
VS Code Setup - Setting up a development environment in Visual Studio Code
Cursor AI Integration - Guide for integrating TomTom Maps MCP server with Cursor AI
Windsurf Integration - Instructions for configuring Windsurf to use TomTom Maps MCP server
Smolagents Integration - Example showing how to connect Smolagents AI agents to TomTom Maps MCP server.
By default the MCP tools use TomTom Maps APIs listed above. We also support using TomTom Orbis Maps for the same tools. To enable TomTom Orbis Maps for all tools set the environment variable MAPS=tomtom-orbis-maps.
Note: The Orbis Maps backend includes all the tools from TomTom Maps plus additional Orbis-exclusive tools:
tomtom-ev-routing,tomtom-search-along-route,tomtom-area-search,tomtom-ev-search, andtomtom-data-viz. Thetomtom-static-maptool is only available with the default TomTom Maps backend.
Tool | Description | TomTom Orbis Maps API (documentation) |
| Forward geocoding: address → coordinates | https://developer.tomtom.com/geocoding-api/documentation/tomtom-orbis-maps/geocode |
| Reverse geocoding: coordinates → address | https://developer.tomtom.com/reverse-geocoding-api/documentation/tomtom-orbis-maps/reverse-geocode |
| General search with typo tolerance and suggestions | https://developer.tomtom.com/search-api/documentation/tomtom-orbis-maps/search-service/fuzzy-search |
| Points of Interest (category-based) search | |
| Find POIs near a coordinate within a radius | https://developer.tomtom.com/search-api/documentation/tomtom-orbis-maps/search-service/nearby-search |
| Calculate optimal route between two points | https://developer.tomtom.com/routing-api/documentation/tomtom-orbis-maps/calculate-route |
| Multi-stop / waypoint route planning | https://developer.tomtom.com/routing-api/documentation/tomtom-orbis-maps/calculate-route |
| Compute coverage area by time or distance budget | https://developer.tomtom.com/routing-api/documentation/tomtom-orbis-maps/calculate-reachable-range |
| Traffic incidents and related details | https://developer.tomtom.com/traffic-api/documentation/tomtom-orbis-maps/incident-details |
| Advanced map rendering with custom markers, routes, and traffic visualization | https://developer.tomtom.com/map-display-api/documentation/tomtom-orbis-maps/raster-tile |
| Plan long-distance EV routes with automatic charging stop optimization | https://developer.tomtom.com/routing-api/documentation/tomtom-orbis-maps/long-distance-ev-routing |
| Find POIs (restaurants, gas stations, hotels, etc.) along a route corridor | |
| Search for places within a geographic area (circle, polygon, or bounding box) | |
| Find EV charging stations with real-time availability and connector types | |
| Visualize custom GeoJSON data on an interactive TomTom basemap (markers, heatmaps, clusters, choropleths) | https://developer.tomtom.com/map-display-api/documentation/tomtom-orbis-maps/raster-tile |
The dynamic map tool fetches raster tiles from TomTom (either TomTom Maps or TomTom Orbis Maps), then uses skia-canvas (server-side) to:
stitch map tiles into a single canvas at the appropriate zoom level;
add markers, routes, polygons, and other overlays;
render the final composited image.
The server converts the rendered image to PNG and returns it as a Base64 string.
References:
TomTom Map Tile API: https://developer.tomtom.com/map-display-api/documentation/raster/map-tile
TomTom Orbis Maps Tile API: https://developer.tomtom.com/map-display-api/documentation/tomtom-orbis-maps/raster-tile
A built-in debug UI lets you visually test MCP tools and their interactive map widgets without needing an AI client.
pnpm run uiThis starts both the MCP HTTP server (port 3000) and the debug UI host (port 8080). Open http://localhost:8080 in your browser.
Tool browser — searchable sidebar listing all available tools, with icons distinguishing map-enabled tools from plain tools
Pre-filled examples — each tool loads with example parameters (including show_ui: true for map widgets)
Live map widgets — tools with UI resources render interactive TomTom maps directly in the browser
Response metadata — latency, payload size, estimated token count, content parts, and timestamps for every call
Dark / light mode — toggle with the theme button or follows system preference
Keyboard shortcuts — Cmd+Enter to run, Cmd+K to search tools
The MCP server must be running in HTTP mode (handled automatically by pnpm run ui)
A valid TOMTOM_API_KEY in your .env file
To see map widgets, use the TomTom Orbis Maps backend (MAPS=tomtom-orbis-maps in .env)
The UI host is a workspace package (tomtom-mcp-app-host in ui/), so the root pnpm install already installed its dependencies.
pnpm run ui:build # Build the UI
pnpm --filter tomtom-mcp-app-host start # Start only the UI host (assumes MCP server is already running)This project uses pnpm (
>=11) as its package manager. Install it withnpm install -g pnpmorcorepack enable. Linting and formatting are handled by Biome.
git clone https://github.com/tomtom-international/tomtom-maps-mcp.git
cd tomtom-maps-mcp
pnpm install
cp .env.example .env # Add your API key in .env
pnpm run build # Build TypeScript files
node ./bin/tomtom-mcp.js # Start the MCP server
pnpm run build # Build TypeScript
pnpm test # Run all tests
pnpm run test:all # All tests (unit + stdio + http)⚠️ Important: All tests require a valid API key in .env as they make real API calls (not mocked). This will consume your API quota.
src/
├── apps/ # MCP App UI resources
├── handlers/ # Request handlers
├── schemas/ # Validation schemas
├── services/ # TomTom API wrappers
├── tools/ # MCP tool definitions
├── types/ # TypeScript type definitions
├── utils/ # Utilities
├── createServer.ts # MCP Server creation logic
├── index.ts # Main entry point (stdio)
└── indexHttp.ts # HTTP server entry pointecho $TOMTOM_API_KEY # Check if setls -la .env # Verify .env exists
cat .env # Check API keypnpm run build # Rebuild
pnpm store prune # Clear cacheIf you see an error stating "missing permissions", it means your API key does not have access to the TomTom Orbis Maps or EV services.
Note: TomTom Orbis Maps and certain EV routing features are currently in Public Preview. They may not be available on all developer accounts by default.
How to troubleshoot:
Log in to the TomTom Developer Portal.
Ensure all available products are selected for your API key.
If you still encounter 403 errors when using MAPS=tomtom-orbis-maps, your account may not yet have access to the Orbis preview. You can continue using the standard tomtom-maps backend in the meantime.
We welcome contributions to the TomTom Maps MCP Server! Please see CONTRIBUTING.md for details on how to submit pull requests, report issues, and suggest improvements.
All contributions must adhere to our Code of Conduct and be signed-off according to the Developer Certificate of Origin (DCO).
Open issues on the GitHub repo
Please see our Security Policy for information on reporting security vulnerabilities and our security practices.
This project is licensed under the Apache License 2.0 - see the LICENSE.md file for details.
Copyright (C) 2025 TomTom Navigation B.V.
| Name | Required | Description | Default |
|---|---|---|---|
| addressRanges | No | Include address ranges in the response | |
| brandSet | No | Filter by brand names. Examples: 'Starbucks,Peet\'s', 'Marriott,Hilton'. Use quotes for brands with commas. | |
| btmRight | No | Bottom-right coordinates of bounding box (format: 'lat,lon'). Must be used with topLeft | |
| categorySet | No | Filter by POI categories. Common IDs: '7315' (restaurants), '7309' (gas), '7311' (hotels), '9663' (EV charging). | |
| connectorSet | No | EV connector types: 'IEC62196Type2CableAttached', 'Chademo', 'TeslaConnector' | |
| connectors | No | Include connector information for EV stations | |
| countrySet | No | Limit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US' | |
| entityTypeSet | No | Filter results by entity types | |
| ext | No | Extended parameters for the search | |
| extendedPostalCodesFor | No | Include extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI' | |
| fuelSet | No | Fuel types: 'Petrol', 'Diesel', 'LPG', 'Hydrogen', 'E85' | |
| geometries | No | Include geometries information in the response | |
| gomList | No | Include geometry-only matches in the result list | |
| idxSet | No | Filter results by index set | |
| language | No | Preferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES' | |
| lat | No | Center latitude for location bias | |
| limit | No | Maximum number of results to return (1-100). Default: 5 | |
| lon | No | Center longitude for location bias | |
| mapcodes | No | 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). | |
| maxFuzzyLevel | No | Maximum fuzzy matching level (1-4) | |
| maxPowerKW | No | Maximum charging power in kW for EV stations | |
| minFuzzyLevel | No | Minimum fuzzy matching level (1-4) | |
| minPowerKW | No | Minimum charging power in kW for EV stations | |
| ofs | No | Offset for pagination of results | |
| openingHours | No | List of opening hours for a POI (Points of Interest).Value: `nextSevenDays` Mode shows the opening hours for next week, starting with the current day in the local time of the POI. Usage example: openingHours=nextSevenDays | |
| query | Yes | Natural language search query. Works with addresses, POI names, coordinates, or free-form text. Examples: 'restaurants near Central Park', 'IKEA stores', '52.3791,4.8994', 'coffee shops downtown' | |
| radius | No | Search radius in meters when lat/lon provided. Examples: 1000 (neighborhood), 5000 (city area), 20000 (metro area). | |
| relatedPois | No | Include related points of interest | |
| roadUse | No | Include road usage information | |
| sort | No | Sort options for results | |
| timeZone | No | 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 | |
| topLeft | No | Top-left coordinates of bounding box (format: 'lat,lon'). Must be used with btmRight | |
| typeahead | No | Enable autocomplete mode for partial queries. Use for search-as-you-type interfaces. | |
| vehicleTypeSet | No | A comma-separated list of vehicle types that could be used to restrict the result to the Points Of Interest of specific vehicles. If vehicleTypeSet is specified, the query can remain empty. Only POIs with a proper vehicle type will be returned. Value: A comma-separated list of vehicle type identifiers (in any order). When multiple vehicles types are provided, only POIs that belong to (at least) one of the vehicle types from the provided list will be returned. Available vehicle types: Car , Truck | |
| view | No | Geopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| addressRanges | No | Include address ranges in the response | |
| btmRight | No | Bottom-right coordinates of bounding box (format: 'lat,lon'). Must be used with topLeft | |
| countrySet | No | Limit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US' | |
| entityTypeSet | No | 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 | |
| extendedPostalCodesFor | No | Include extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI' | |
| geometries | No | Include geometries information in the response | |
| language | No | Preferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES' | |
| lat | No | Center latitude for location bias | |
| limit | No | Maximum number of results to return (1-100). Default: 5 | |
| lon | No | Center longitude for location bias | |
| mapcodes | No | 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). | |
| query | Yes | Full 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' | |
| radius | No | Search radius in meters when lat/lon provided | |
| timeZone | No | 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 | |
| topLeft | No | Top-left coordinates of bounding box (format: 'lat,lon'). Must be used with btmRight | |
| view | No | Geopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| addressRanges | No | Include address ranges in the response | |
| brandSet | No | Filter by brand names. Examples: 'Starbucks,Peet\'s', 'Marriott,Hilton'. Use quotes for brands with commas. | |
| categorySet | No | POI category filter. Common: '7315' (restaurants), '7309' (gas), '9663' (EV charging), '7311' (hotels), '9376' (parking). | |
| chargingAvailability | No | Include charging availability information for EV stations | |
| connectorSet | No | EV connector types: 'IEC62196Type2CableAttached', 'Chademo', 'TeslaConnector' | |
| countrySet | No | Limit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US' | |
| entityTypeSet | No | Filter results by entity types | |
| ext | No | Extended parameters for the search | |
| extendedPostalCodesFor | No | Include extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI' | |
| fuelAvailability | No | Include fuel availability information for gas stations | |
| fuelSet | No | Fuel types: 'Petrol', 'Diesel', 'LPG', 'Hydrogen', 'E85' | |
| geometries | No | Include geometries information in the response | |
| language | No | Preferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES' | |
| lat | Yes | Center latitude for nearby search. Use precise coordinates from geocoding. | |
| limit | No | Maximum number of results to return (1-100). Default: 5 | |
| lon | Yes | Center longitude for nearby search. Use precise coordinates from geocoding. | |
| mapcodes | No | 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). | |
| maxFuzzyLevel | No | Maximum fuzzy matching level (1-4) | |
| maxPowerKW | No | Maximum charging power in kW for EV stations | |
| minFuzzyLevel | No | Minimum fuzzy matching level (1-4) | |
| minPowerKW | No | Minimum charging power in kW for EV stations | |
| ofs | No | Offset for pagination of results | |
| openingHours | No | List of opening hours for a POI (Points of Interest).Value: `nextSevenDays` Mode shows the opening hours for next week, starting with the current day in the local time of the POI. Usage example: openingHours=nextSevenDays | |
| parkingAvailability | No | Include parking availability information | |
| radius | No | Search radius in meters. Default: 1000. Recommended: 500 (walking), 1000 (local), 5000 (driving), 20000 (wide area). | |
| relatedPois | No | Include related points of interest | |
| roadUse | No | Include road usage information | |
| sort | No | Sort options for results | |
| timeZone | No | 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 | |
| vehicleTypeSet | No | A comma-separated list of vehicle types that could be used to restrict the result to the Points Of Interest of specific vehicles. If vehicleTypeSet is specified, the query can remain empty. Only POIs with a proper vehicle type will be returned. Value: A comma-separated list of vehicle type identifiers (in any order). When multiple vehicles types are provided, only POIs that belong to (at least) one of the vehicle types from the provided list will be returned. Available vehicle types: Car , Truck | |
| view | No | Geopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| addressRanges | No | Include address ranges in the response | |
| brandSet | No | Filter by brand names. Examples: 'Starbucks,Peet\'s', 'Marriott,Hilton'. Use quotes for brands with commas. | |
| btmRight | No | Bottom-right coordinates of bounding box (format: 'lat,lon'). Must be used with topLeft | |
| categorySet | No | Filter by POI categories. Common IDs: '7315' (restaurants), '7309' (gas), '7311' (hotels), '9663' (EV charging). | |
| chargingAvailability | No | Include charging availability information for EV stations | |
| connectorSet | No | EV connector types: 'IEC62196Type2CableAttached', 'Chademo', 'TeslaConnector' | |
| countrySet | No | Limit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US' | |
| entityTypeSet | No | Filter results by entity types | |
| ext | No | Extended parameters for the search | |
| extendedPostalCodesFor | No | Include extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI' | |
| fuelAvailability | No | Include fuel availability information for gas stations | |
| fuelSet | No | Fuel types: 'Petrol', 'Diesel', 'LPG', 'Hydrogen', 'E85' | |
| geometries | No | Include geometries information in the response | |
| language | No | Preferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES' | |
| lat | No | Latitude for location context. STRONGLY recommended for relevant local results. | |
| limit | No | Maximum number of results to return (1-100). Default: 5 | |
| lon | No | Longitude for location context. Must be used with lat parameter. | |
| mapcodes | No | 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). | |
| maxFuzzyLevel | No | Maximum fuzzy matching level (1-4) | |
| maxPowerKW | No | Maximum charging power in kW for EV stations | |
| minFuzzyLevel | No | Minimum fuzzy matching level (1-4) | |
| minPowerKW | No | Minimum charging power in kW for EV stations | |
| ofs | No | Offset for pagination of results | |
| openingHours | No | List of opening hours for a POI (Points of Interest).Value: `nextSevenDays` Mode shows the opening hours for next week, starting with the current day in the local time of the POI. Usage example: openingHours=nextSevenDays | |
| parkingAvailability | No | Include parking availability information | |
| query | Yes | Specific POI category search. Best for finding types of businesses: 'restaurants', 'gas stations', 'hotels', 'parking', 'ATMs', 'hospitals' | |
| radius | No | Search radius in meters. Essential for focused local results. Examples: 1000 (walking), 5000 (driving), 20000 (wide area). | |
| relatedPois | No | Include related points of interest | |
| roadUse | No | Include road usage information | |
| sort | No | Sort options for results | |
| timeZone | No | 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 | |
| topLeft | No | Top-left coordinates of bounding box (format: 'lat,lon'). Must be used with btmRight | |
| typeahead | No | Autocomplete mode for partial queries. Use for search interfaces. | |
| vehicleTypeSet | No | A comma-separated list of vehicle types that could be used to restrict the result to the Points Of Interest of specific vehicles. If vehicleTypeSet is specified, the query can remain empty. Only POIs with a proper vehicle type will be returned. Value: A comma-separated list of vehicle type identifiers (in any order). When multiple vehicles types are provided, only POIs that belong to (at least) one of the vehicle types from the provided list will be returned. Available vehicle types: Car , Truck | |
| view | No | Geopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| accelerationEfficiency | No | Efficiency during acceleration (0-1). | |
| auxiliaryPowerInLitersPerHour | No | Auxiliary power consumption for combustion vehicles in L/hr. | |
| auxiliaryPowerInkW | No | Auxiliary power consumption in kW for electric vehicles. | |
| avoid | No | Route features to avoid. May increase travel time. Options: 'tollRoads','motorways','ferries','unpavedRoads','carpools','alreadyUsedRoads'. Accepts array of string(s). | |
| chargeMarginsInkWh | No | Comma-separated charge margins in kWh for route planning. | |
| constantSpeedConsumptionInLitersPerHundredkm | No | Combustion speed-to-consumption mappings: '50,6.3:130,11.5' (speed in km/h, consumption in L/100km). | |
| constantSpeedConsumptionInkWhPerHundredkm | No | EV speed-to-consumption mappings format: '50,8.2:130,21.3' (speed in km/h, consumption in kWh/100km). | |
| consumptionInkWhPerkmAltitudeGain | No | Energy used per km of altitude gain. | |
| currentChargeInkWh | No | Current EV battery charge in kWh. Required for EV routing. | |
| currentFuelInLiters | No | Current fuel level in liters for combustion vehicles. | |
| decelerationEfficiency | No | Efficiency during deceleration (0-1). | |
| departAt | No | Departure time in ISO format (e.g., '2025-06-24T14:30:00Z'). | |
| distanceBudgetInMeters | No | Maximum travel distance in meters. Examples: 5000 (5km), 10000 (10km), 20000 (20km). Either time or distance budget required. | |
| downhillEfficiency | No | Efficiency during downhill driving (0-1). | |
| energyBudgetInkWh | No | Maximum energy budget in kWh for electric vehicles. Example: 10 (10 kWh). | |
| fuelBudgetInLiters | No | Maximum fuel budget in liters for combustion vehicles. Example: 5 (5 liters). | |
| fuelEnergyDensityInMJoulesPerLiter | No | Fuel energy density in megajoules per liter. | |
| hilliness | No | Preference for avoiding hills. Use 'low' for flatter routes. This can be only used when `routeType` parameter is set to `thrilling`. | |
| maxChargeInkWh | No | Maximum EV battery capacity in kWh. Required for EV routing. | |
| maxFerryLengthInMeters | No | Maximum allowed ferry length in meters. | |
| origin | Yes | Starting point for reachable area calculation. Typically current location or point of interest. | |
| recuperationInkWhPerkmAltitudeLoss | No | Energy recovered per km of altitude loss. | |
| 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 | |
| routeType | No | Route optimization: 'fastest' (time-optimized), 'shortest' (distance-optimized), 'eco' (fuel-efficient). | |
| timeBudgetInSec | No | Maximum travel time in seconds. Examples: 900 (15min), 1800 (30min), 3600 (1h). Either time or distance budget required. | |
| traffic | No | Include real-time traffic data for more accurate reachable area calculation. | |
| travelMode | No | Travel mode affects reachable area shape. Default: 'car'. Note: Pedestrian/bicycle modes not supported by API. | |
| uphillEfficiency | No | Efficiency during uphill driving (0-1). | |
| vehicleAdrTunnelRestrictionCode | No | ADR tunnel restriction code for hazardous materials. | |
| 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. | |
| vehicleHeight | No | Vehicle height in meters. Used to avoid low bridges. | |
| vehicleLength | No | Vehicle length in meters. Affects maneuverability restrictions. | |
| vehicleLoadType | No | Cargo type for hazardous materials routing. | |
| vehicleMaxSpeed | No | Maximum vehicle speed in km/h for commercial routing. | |
| vehicleNumberOfAxles | No | Number of axles on the vehicle. Used for toll calculations and restrictions. | |
| vehicleWeight | No | Vehicle weight in kg. Important for truck routing restrictions. | |
| vehicleWidth | No | Vehicle width in meters. Used to avoid narrow roads. | |
| windingness | No | Preference for avoiding winding roads. Use 'low' for straighter routes. This can be only used when `routeType` parameter is set to `thrilling`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| addressRanges | No | Include address ranges in the response | |
| allowFreeformNewLine | No | Allow newlines in freeform addresses | |
| countrySet | No | Limit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US' | |
| entityTypeSet | No | Filter by entity types: 'Country', 'Municipality', etc. | |
| extendedPostalCodesFor | No | Include extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI' | |
| geometries | No | Include geometries information in the response | |
| heading | No | Heading direction in degrees (0-360) for improved accuracy on roads | |
| language | No | Preferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES' | |
| lat | Yes | Latitude coordinate (-90 to +90). Precision to 4+ decimal places recommended. | |
| limit | No | Maximum number of results to return (1-100). Default: 5 | |
| lon | Yes | Longitude coordinate (-180 to +180). Precision to 4+ decimal places recommended. | |
| mapcodes | No | 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). | |
| maxResults | No | Maximum results to return (alias for limit) | |
| ofs | No | Offset for pagination of results | |
| radius | No | Search radius in meters. Default: 100 | |
| returnAddressNames | No | Include address names in the response | |
| returnCommune | No | Include commune information in the results | |
| returnMatchType | No | Include information about the type of geocoding match achieved | |
| returnRoadAccessibility | No | Include road accessibility information | |
| returnRoadUse | No | Include road use types for street level results | |
| returnSpeedLimit | No | Include posted speed limit for street results | |
| roadUse | No | Types of road use to include in the results. Examples: 'Arterial', 'Ferry', 'Highway', etc. | |
| timeZone | No | 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 | |
| view | No | Geopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| accelerationEfficiency | No | Efficiency during acceleration (0-1). | |
| 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` | |
| arriveAt | No | Arrival time in ISO format (e.g., '2025-06-24T17:00:00Z'). Cannot be used with departAt. | |
| auxiliaryPowerInLitersPerHour | No | Auxiliary power consumption for combustion vehicles in L/hr. | |
| auxiliaryPowerInkW | No | Auxiliary power consumption in kW for electric vehicles. | |
| avoid | No | Route features to avoid. May increase travel time. Options: 'tollRoads','motorways','ferries','unpavedRoads','carpools','alreadyUsedRoads'. Accepts array of string(s). | |
| chargeMarginsInkWh | No | Comma-separated charge margins in kWh for route planning. | |
| computeBestOrder | No | Reorder waypoints for optimization. Use with multiple waypoints to find the most efficient route order. | |
| computeTravelTimeFor | No | Calculate travel times for all segments ('all') or none ('none'). | |
| constantSpeedConsumptionInLitersPerHundredkm | No | Combustion speed-to-consumption mappings: '50,6.3:130,11.5' (speed in km/h, consumption in L/100km). | |
| constantSpeedConsumptionInkWhPerHundredkm | No | EV speed-to-consumption mappings format: '50,8.2:130,21.3' (speed in km/h, consumption in kWh/100km). | |
| consumptionInkWhPerkmAltitudeGain | No | Energy used per km of altitude gain. | |
| currentChargeInkWh | No | Current EV battery charge in kWh. Required for EV routing. | |
| currentFuelInLiters | No | Current fuel level in liters for combustion vehicles. | |
| decelerationEfficiency | No | Efficiency during deceleration (0-1). | |
| departAt | No | Departure time in ISO format (e.g., '2025-06-24T14:30:00Z'). Cannot be used with arriveAt. | |
| destination | Yes | Destination coordinates. Obtain from geocoding for best results. | |
| downhillEfficiency | No | Efficiency during downhill driving (0-1). | |
| extendedRouteRepresentation | No | Additional routing data formats to include in the response. | |
| fuelEnergyDensityInMJoulesPerLiter | No | Fuel energy density in megajoules per liter. | |
| hilliness | No | Preference for avoiding hills. Use 'low' for flatter routes. | |
| 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 | |
| instructionsType | No | Instruction format: 'text' (human-readable), 'coded' (machine-readable), 'tagged' (HTML). | |
| language | No | Language code for instructions (e.g., 'en-US', 'de-DE'). | |
| maxAlternatives | No | Number of alternative routes (0-5). More alternatives = more options but larger response. | |
| maxChargeInkWh | No | Maximum EV battery capacity in kWh. Required for EV routing. | |
| origin | Yes | Starting point coordinates. Obtain from geocoding for best results. | |
| recuperationInkWhPerkmAltitudeLoss | No | Energy recovered per km of altitude loss. | |
| 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 | |
| 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 | |
| routeType | No | Route optimization: 'fastest' (time-optimized), 'shortest' (distance-optimized), 'eco' (fuel-efficient), 'thrilling' (scenic). | |
| 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. | |
| supportingPoints | No | Additional coordinates that influence the route shape without being stops (format: 'lat,lon;lat,lon'). | |
| traffic | No | Include real-time traffic data for more accurate ETAs and route suggestions. | |
| travelMode | No | Transportation mode. Default: 'car'. | |
| uphillEfficiency | No | Efficiency during uphill driving (0-1). | |
| vehicleAdrTunnelRestrictionCode | No | ADR tunnel restriction code for hazardous materials. | |
| 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. | |
| vehicleHeading | No | Heading of the vehicle in degrees (0-359) for more accurate initial routing. | |
| vehicleHeight | No | Vehicle height in meters. Used to avoid low bridges. | |
| vehicleLength | No | Vehicle length in meters. Affects maneuverability restrictions. | |
| vehicleLoadType | No | Cargo type for hazardous materials routing. | |
| vehicleMaxSpeed | No | Maximum vehicle speed in km/h for commercial routing. | |
| vehicleNumberOfAxles | No | Number of axles on the vehicle. Used for toll calculations and restrictions. | |
| vehicleWeight | No | Vehicle weight in kg. Important for truck routing restrictions. | |
| vehicleWidth | No | Vehicle width in meters. Used to avoid narrow roads. | |
| windingness | No | Preference for avoiding winding roads. Use 'low' for straighter routes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | Bounding box in format [west, south, east, north]. Alternative to center+zoom. Example: [-122.42, 37.77, -122.40, 37.79] for part of San Francisco. | |
| center | Yes | Map center coordinates. Use results from geocoding or search operations for best positioning. | |
| format | No | Image format: 'png' (better quality, supports transparency), 'jpg' (smaller file size). | |
| height | No | Map height in pixels (50-2048). Examples: 300-500 (preview), 800-1200 (detailed). Default: 512. | |
| language | No | Language for map labels (IETF language tag). Examples: 'en-US', 'es-ES', 'fr-FR'. | |
| layer | No | Map layer type: 'basic' (streets), 'labels' (text only, transparent background), 'hybrid' (satellite with labels). | |
| style | No | Map style: 'main' (default daytime), 'night' (dark theme). | |
| view | No | Geopolitical view for border disputes and territories. 'Unified' is the international standard view. | |
| width | No | Map width in pixels (50-2048). Examples: 300-500 (preview), 800-1200 (detailed). Default: 512. | |
| zoom | No | Zoom level (0-22). Examples: 3 (continent), 6 (country), 10 (city), 15 (neighborhood), 18 (street). Default: 15. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | Bounding box for traffic area: 'minLon,minLat,maxLon,maxLat'. Example: '-74.02,40.70,-73.96,40.80' for lower Manhattan. Use smaller areas for better results. | |
| categoryFilter | No | Filter by incident categories (comma-separated): '0' (Accident), '1' (Fog), '2' (Dangerous Conditions), '3' (Rain), '4' (Ice), '5' (Lane Restrictions), '6' (Lane Closure), '7' (Road Closure), '8' (Road Works), '9' (Wind), '10' (Flooding), '11' (Detour), '14' (Cluster). | |
| incidentTypes | No | Filter by incident types (comma-separated): '0' (Accident), '1' (Fog), '4' (Ice), '5' (Lane Restrictions), '7' (Closure), '8' (Roadworks). | |
| language | No | Language for incident descriptions: 'en-US', 'de-DE', 'fr-FR', 'es-ES'. Default: 'en-US'. | |
| maxResults | No | Maximum incidents to return (1-1000). Use 10-20 for readability in high-traffic areas. | |
| t | No | Unix Timestamp in seconds for traffic model. Use current time if not provided. | |
| timeFilter | No | Time validity filter: 'present' (current), 'future' (upcoming), 'all' (both). Default: 'present'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| accelerationEfficiency | No | Efficiency during acceleration (0-1). | |
| 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` | |
| arriveAt | No | Arrival time in ISO format (e.g., '2025-06-24T17:00:00Z'). Cannot be used with departAt. | |
| auxiliaryPowerInLitersPerHour | No | Auxiliary power consumption for combustion vehicles in L/hr. | |
| auxiliaryPowerInkW | No | Auxiliary power consumption in kW for electric vehicles. | |
| avoid | No | Route features to avoid. May increase travel time. Options: 'tollRoads','motorways','ferries','unpavedRoads','carpools','alreadyUsedRoads'. Accepts array of string(s). | |
| chargeMarginsInkWh | No | Comma-separated charge margins in kWh for route planning. | |
| computeBestOrder | No | Reorder waypoints for optimization. Use with multiple waypoints to find the most efficient route order. | |
| computeTravelTimeFor | No | Calculate travel times for all segments ('all') or none ('none'). | |
| constantSpeedConsumptionInLitersPerHundredkm | No | Combustion speed-to-consumption mappings: '50,6.3:130,11.5' (speed in km/h, consumption in L/100km). | |
| constantSpeedConsumptionInkWhPerHundredkm | No | EV speed-to-consumption mappings format: '50,8.2:130,21.3' (speed in km/h, consumption in kWh/100km). | |
| consumptionInkWhPerkmAltitudeGain | No | Energy used per km of altitude gain. | |
| currentChargeInkWh | No | Current EV battery charge in kWh. Required for EV routing. | |
| currentFuelInLiters | No | Current fuel level in liters for combustion vehicles. | |
| decelerationEfficiency | No | Efficiency during deceleration (0-1). | |
| departAt | No | Departure time in ISO format (e.g., '2025-06-24T14:30:00Z'). Cannot be used with arriveAt. | |
| downhillEfficiency | No | Efficiency during downhill driving (0-1). | |
| extendedRouteRepresentation | No | Additional routing data formats to include in the response. | |
| fuelEnergyDensityInMJoulesPerLiter | No | Fuel energy density in megajoules per liter. | |
| hilliness | No | Preference for avoiding hills. Use 'low' for flatter routes. | |
| 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 | |
| instructionsType | No | Instruction format: 'text' (human-readable), 'coded' (machine-readable), 'tagged' (HTML). | |
| language | No | Language code for instructions (e.g., 'en-US', 'de-DE'). | |
| maxAlternatives | No | Number of alternative routes (0-5). More alternatives = more options but larger response. | |
| maxChargeInkWh | No | Maximum EV battery capacity in kWh. Required for EV routing. | |
| recuperationInkWhPerkmAltitudeLoss | No | Energy recovered per km of altitude loss. | |
| 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 | |
| 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 | |
| routeType | No | Route optimization: 'fastest' (time-optimized), 'shortest' (distance-optimized), 'eco' (fuel-efficient), 'thrilling' (scenic). | |
| 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). | |
| supportingPoints | No | Additional coordinates that influence the route shape without being stops (format: 'lat,lon;lat,lon'). | |
| traffic | No | Include real-time traffic data for more accurate ETAs and route suggestions. | |
| travelMode | No | Transportation mode. Default: 'car'. | |
| uphillEfficiency | No | Efficiency during uphill driving (0-1). | |
| vehicleAdrTunnelRestrictionCode | No | ADR tunnel restriction code for hazardous materials. | |
| 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. | |
| vehicleHeading | No | Heading of the vehicle in degrees (0-359) for more accurate initial routing. | |
| vehicleHeight | No | Vehicle height in meters. Used to avoid low bridges. | |
| vehicleLength | No | Vehicle length in meters. Affects maneuverability restrictions. | |
| vehicleLoadType | No | Cargo type for hazardous materials routing. | |
| vehicleMaxSpeed | No | Maximum vehicle speed in km/h for commercial routing. | |
| vehicleNumberOfAxles | No | Number of axles on the vehicle. Used for toll calculations and restrictions. | |
| vehicleWeight | No | Vehicle weight in kg. Important for truck routing restrictions. | |
| vehicleWidth | No | Vehicle width in meters. Used to avoid narrow roads. | |
| waypoints | Yes | Ordered array of waypoint coordinates (minimum 2). Route calculated in exact sequence provided. Use geocoding for accurate coordinates. | |
| windingness | No | Preference for avoiding winding roads. Use 'low' for straighter routes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose based on its name: fuzzy-search, geocode, nearby, poi-search, reachable-range, reverse-geocode, routing, static-map, traffic, and waypoint-routing. There is no overlap or ambiguity between these tools as they target different geographic and mapping functions.
All tool names follow a consistent pattern: 'tomtom-' prefix followed by a hyphenated descriptive term (e.g., fuzzy-search, geocode). This uniform naming convention makes the tool set predictable and easy to understand.
With 10 tools, this server is well-scoped for a mapping and location services domain. Each tool appears to serve a specific, non-redundant function, making the count appropriate and manageable.
The tool set covers core mapping operations like geocoding, routing, POI search, and traffic, with no obvious gaps for basic functionality. However, without descriptions, it's unclear if advanced features (e.g., batch processing or custom map styling) are missing, but the surface seems largely complete for typical use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides AI assistants with direct access to Mapbox developer APIs and documentation.
TomTom MCP — wraps the TomTom Search & Routing APIs (api.tomtom.com)
Geolocate Me turns your phone into location context for any AI assistant. Install the iOS or Android app, connect once with OAuth, and your GPS is queryable in natural language. Ask where you are, where you parked, where you were yesterday at 3pm, or how long you were at the office — the assistant calls the tool and answers with a real street address. https://geolocateme.app
Geospatial intelligence with Mapbox APIs like geocoding, POI search, directions, isochrones, etc.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tomtom-international/tomtom-maps-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
