TomTom Maps MCP Server provides geospatial location services for AI workflows via TomTom APIs.
Geocode addresses to coordinates and reverse geocode coordinates to addresses.
Search for addresses/places with fuzzy search, POI name or category search, nearby search, area-bound search, and POI category lookup.
Find EV charging stations with connector and power filters.
Search for POIs along a route corridor.
Calculate routes through an origin, optional stops, and destination with traffic, avoidance, and route-type options.
Retrieve traffic incidents and details within a bounding box.
Render interactive maps with markers, lines, polygons, circles, and calculated route plans in MCP apps.
Visualize custom GeoJSON data with markers, heatmaps, clusters, lines, fills, and choropleths.
Return compact, geometry, or full responses for token efficiency or downstream geometry use.
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 "Deploy 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 interactive maps. 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"
}
}
}
}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 | - |
| Port for the HTTP server |
|
| Logging level: |
|
| Stdio only. | - |
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:
tomtom-api-key: <API_KEY>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
docker run -p 3000:3000 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
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.
Tool | Description | Documentation |
| Forward geocoding: address → coordinates | https://developer.tomtom.com/geocoding-api/documentation/tomtom-orbis-maps/geocode |
| Reverse geocoding: coordinates → address | |
| 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 |
| List the POI categories available for search | |
| Calculate optimal route through an origin, optional stops and a destination | https://developer.tomtom.com/routing-api/documentation/tomtom-orbis-maps/calculate-route |
| Traffic incidents and related details | https://developer.tomtom.com/traffic-api/documentation/tomtom-orbis-maps/incident-details |
| Interactive map with custom markers, routes and polygons, rendered by the MCP app | https://developer.tomtom.com/map-display-api/documentation/tomtom-orbis-maps/vector-style |
| 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 their connector types and power levels | |
| Visualize custom GeoJSON data on an interactive TomTom basemap (markers, heatmaps, clusters, choropleths) | https://developer.tomtom.com/map-display-api/documentation/tomtom-orbis-maps/vector-style |
A tool removed in an earlier release is no longer listed, but calling it by name still returns an error that names the tool to use instead, or says why none does. The error's details hold the tool, the last release that listed it, and replacedBy: the replacements your client is offered.
A tool that kept its name and changed its inputs does the same for a call that still uses the old ones: the error says what changed, and the call does not run. details holds the tool, the last release that had the previous contract, and inputs, the arguments that triggered it.
The dynamic map tool renders nothing server-side. It resolves the request into map state — the basemap style to load, the viewport to open on, and GeoJSON sources and layers for the markers, routes and polygons requested — calculating any routePlans through the Routing API along the way.
The tool hands that state to the MCP app inside its result, with long route lines simplified to fit. When a host drops it, the app shows an error rather than calling TomTom a second time. The app draws the map client-side, so panning, zooming and clicking work on a live map.
Because the map is drawn by the app, the visual requires an MCP client that supports MCP apps. A client the server knows renders no MCP apps, such as Claude Code, Gemini CLI, Cline or Zed, does not get tomtom-dynamic-map, tomtom-data-viz, the app-only tools or show_ui at all (see Clients without MCP apps). Any other client without MCP apps receives a JSON summary of what the map shows: its view, markers, routes (distance, travel time, traffic delay) and areas.
When a client connects, its initialize request decides what it gets, over stdio and HTTP alike:
The client | Gets |
advertises the MCP Apps extension ( | every tool, with maps |
is known to render no MCP apps, by its | the data tools only, without |
neither | every tool, as before: some clients render apps without advertising the extension |
The HTTP server keeps no state, so its initialize response returns an Mcp-Session-Id of the form <apps>.<client>.<uuid> recording this classification and the client's clientInfo.name, base64url-encoded (or unknown without one), and the client sends it with every later request. The name is also reported as client in the TomTom-Upstream-Metadata response header, next to auth_method, for the gateway's analytics. A request without an Mcp-Session-Id, as ChatGPT sends its tool calls, is named by its raw User-Agent instead.
A client can also choose for itself, which is useful for a headless agent or a client in the last row. Over HTTP, add ?apps=false to the MCP URL (for example https://mcp.tomtom.com/maps?apps=false) for the data tools only, or ?apps=true for every tool. Over stdio, set MCP_APPS=false or MCP_APPS=true in the server's environment.
The map apps load MapLibre GL JS from https://cdn.jsdelivr.net rather than bundling it, so the client must be able to reach jsDelivr as well as api.tomtom.com. Both are declared in the apps' content security policy. MapLibre's worker is bundled into each app instead, because ChatGPT's sandbox allows workers only from blob: URLs.
References:
TomTom Orbis Maps style: https://developer.tomtom.com/map-display-api/documentation/tomtom-orbis-maps/vector-style
Every tool that returns TomTom data accepts a response_detail parameter (all but tomtom-poi-categories, tomtom-dynamic-map and tomtom-data-viz). The four tools that return geometry (tomtom-routing, tomtom-traffic, tomtom-area-search and tomtom-search-along-route) accept three values; the others accept compact and full.
Value | Returns |
| Essential fields and the point coordinates of a place. No geometry: route lines, traffic incident locations and search areas are omitted. |
|
|
| The raw API response: lossless, in the API's own shape, and many times larger. |
The default is tuned for conversational use, where a route line would consume most of a model's context for no benefit. If you are building on top of the server and need the coordinates themselves, to draw the result on your own map or run your own analysis, request response_detail: "geometry". Use full only when you need fields that compact drops, or the exact line.
For an Amsterdam-to-Berlin route, geometry is about 22 KB: the 8,000-point line is simplified to 1,000 vertices, at most 13 m from the original. full is about 210 KB.
geometry FeatureCollection{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"properties": { "summary": { "lengthInMeters": 663425, "travelTimeInSeconds": 24453 } }
}
],
"geometry": {
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"geometry": { "type": "LineString", "coordinates": [[4.90413, 52.36761], [4.90419, 52.36755]] },
"properties": {
"route": 0,
"simplification": { "original_points": 8151, "points": 1000, "max_error_m": 13 }
}
}
]
}
}Coordinates follow RFC 7946: [longitude, latitude], rounded to 5 decimal places (about 1.1 m). Polygon rings are closed.
One feature per item. Its properties hold only a join key giving the item's position in the rest of the response. A join key is valid within one response only; don't store it as an identifier.
Tool | Features |
|
Routing | One |
|
Traffic | One |
|
Area search | The search boundary |
|
Search along route | The route |
|
At most 1,000 vertices per feature. Longer lines are simplified, and the feature then carries simplification: the original and returned vertex counts, and max_error_m, an upper bound in whole metres on the distance between a dropped vertex and the returned line, including the shift from rounding coordinates to 5 decimals. A long route is accurate at the zoom that shows all of it, but visibly approximate when zoomed in; if max_error_m is too large for your use, request full. A polygon that would cross itself after simplification keeps more vertices instead, so it can exceed 1,000.
No vertex indexes. Route sections and legs point into the API's original line, which a simplified line no longer matches, so geometry responses drop startPointIndex, endPointIndex and pointIndex.
The design is recorded in docs/adr/.
Note: Hosts that support MCP Apps render the interactive map widget from the untrimmed response regardless of this setting, so
compactloses nothing visually. Theshow_uiparameter requests that widget and is ignored by hosts that cannot render it. It adds no coordinates to the text response: the widget's data, coordinates included, travels in the result's_metafor the host to pass to the widget. That field is the result's only_meta. The text carriesshow_ui, and the tool name when the result has app data, so a host that drops the result_metacan still hide the map. For coordinates in the response itself, useresponse_detail: "geometry". Clients known to render no MCP apps don't get the parameter.
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
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: The tests require a valid API key in .env: the service and tool tests make real API calls, which consume your API quota.
pnpm run test:e2e:oauth connects to the deployed MCP server with the MCP SDK client, the library the connectors are built on, and follows the same path a connector does: the server's 401 names the authorization server, the SDK discovers it and opens the authorize request, a browser picks the sign-in tenant and logs the test user in, the SDK redeems the code, and the session calls a tool with the token. It runs for every account and connector of a target, with the same connectors on both targets, so a change on dev is checked the way real users will meet it on prod.
Target | MCP server | Authorization server it must advertise | Connectors | Last step |
|
|
| ChatGPT, Claude | geocode returns a result |
|
|
| ChatGPT, Claude | geocode returns a result |
|
|
| the test client dev serves | geocode returns a result |
The authorization server is discovered from the MCP server, never configured in the test; the test only asserts that the discovered one is the expected one, so a deployment pointing at the wrong ULS instance fails in the first step with that message. The connectors are the registered redirect URIs of ChatGPT and Claude; the sign-in tenant is chosen on the ULS page the way a user does, with no tenant shortcut.
Every target signs in through ULS production: ULS staging issues keys for APIM test, where most API services do not answer, so dev uses production ULS and its own Entra app in the production external tenant, and its exchanged keys serve the production APIs.
Select the target with OAUTH_E2E_TARGET. Accounts come from the environment, .env locally. A missing pair skips that account locally and fails the run in CI, so a misconfigured secret can never pass.
E2E_B2B_EMAIL, E2E_B2B_PASSWORD: workforce user, prod only. The workforce tenant holds no resource app for the dev origin yet, so that login cannot succeed on dev.
E2E_B2C_PROD_EMAIL, E2E_B2C_PROD_PASSWORD: external user on every target, since all of them sign in to the production external tenant.
On prod and dev the test needs no server running and starts none. The browser resolves the connectors' redirect hosts to 127.0.0.1, so a captured authorization code never reaches a third party.
local checks the OAuth path of a build on this machine without a dev deployment. Start the server with the env block of the dev deployment in tomtom-mcp-infra (.kaap/helm/dev/app.yaml), leaving out MCP_BASE_URL and MCP_BASE_URL_PATH so it advertises itself as localhost, then run the test against it:
AUTHORIZATION_SERVER_URL=... ULS_TOKEN_ENDPOINT=... ULS_CLIENT_ID=... CIAM_TENANT_ID=... CIAM_DOMAIN=... WORKFORCE_TENANT_ID=... OAUTH_AUDIENCE=... pnpm run dev:http
OAUTH_E2E_TARGET=local pnpm run test:e2e:oauthOAUTH_AUDIENCE is the comma-separated list of application IDs of the Entra resource apps the tokens are issued for. It is required whenever CIAM_TENANT_ID and CIAM_DOMAIN are set; the server refuses to start without it.
ChatGPT and Claude cannot reach a local server, so local logs in through the test client that dev serves at /maps/inspector-client.json, registered on ULS production with a loopback redirect. That is why local depends on dev being up, and why the workforce account is left out: the dev origin has no workforce resource app.
In CI it runs from tomtom-internal/tomtom-mcp-infra (workflow oauth-e2e.yml) on TomTom's self-hosted runners, because the workforce service account may only sign in from a TomTom IP and tomtom-international has no such runners. That private repository holds the account secrets and checks out main of this one. It runs on a schedule against prod, after every dev or prod image bump in that repository once the rollout serves the new image, and on demand for either target. Scheduled and bump runs post to Slack only when the outcome changes.
pnpm run test:e2e:protocol connects to the server over HTTP and checks what a client sees on the wire: every tool listed with its MCP app, every app resource served as an MCP app with its CSP, and only the usable tools, with no app parts, with ?apps=false. The expected listing is the same table the in-process tests use (src/appListings.ts). It calls no TomTom API.
By default it starts the build in dist (run pnpm build first) and probes it; CI runs it this way on every pull request. PROTOCOL_TARGET=prod or dev probes a deployment instead, with the API key in TOMTOM_API_KEY.
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 cache"TomTom rejected the API key as missing or invalid" is a 401: TomTom does not know the key. Check TOMTOM_API_KEY, or the tomtom-api-key header your client sends, or reconnect to the hosted server to sign in again.
"TomTom refused this request for the API key" is a 403: the key is valid, but the key or its account may not make the request. Either:
The account has used up its free requests for that API. See the free allowances on the pricing page.
The account's plan does not include that API. See the plans on the pricing page.
The API is not among the key's products. Log in to the TomTom Developer Portal and check that your API key has every product this server uses: Search, Geocoding, Reverse Geocoding, Routing, Traffic and Map Display.
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.
Find all POIs within a strict geographic boundary — polygon, bounding box, or circle. Use this when the search must be confined to a specific region (e.g. 'restaurants inside Westminster', 'hotels within this polygon'). Unlike tomtom-nearby (radius from a point) or tomtom-poi-search (location bias), this tool guarantees results are inside the defined geometry. The search area outline is omitted unless response_detail is 'geometry'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (1-100). Default: 10. | |
| query | Yes | What to search for in the area. Examples: 'restaurant', 'hotel', 'parking', 'pharmacy', 'ATM'. | |
| center | No | Center position as [longitude, latitude] for circular area search (GeoJSON convention). Use with radius. Example: [4.89707, 52.377956] for Amsterdam. | |
| radius | No | Radius in meters for circular area search. Required with center. Examples: 500, 1000, 5000. | |
| polygon | No | Polygon vertices as [[longitude, latitude], ...] (GeoJSON convention). Minimum 3 points, automatically closed. Use instead of center/radius for irregular areas. | |
| show_ui | No | Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false | |
| language | No | Language for results (IETF tag). Examples: 'en-US', 'de-DE'. | |
| boundingBox | No | Rectangular bounding box as [[topLeftLon, topLeftLat], [bottomRightLon, bottomRightLat]] (GeoJSON convention). Use instead of center/radius or polygon. Example: [[4.8, 52.45], [4.95, 52.3]] for Amsterdam area. | |
| poiCategories | No | Filter POI results by UPPER_SNAKE_CASE text category codes (e.g. 'RESTAURANT', 'PARKING_GARAGE'), NOT numeric IDs. IMPORTANT: Never guess codes — always call tomtom-poi-categories first with the user's intent as keywords to discover valid codes. | |
| response_detail | No | Response detail level. 'compact' (default): essential fields and point coordinates, no geometry. 'geometry': compact plus a 'geometry' key holding a GeoJSON FeatureCollection ([lon, lat], at most 1,000 vertices per feature); use this to get coordinates to draw or process. 'full': the raw API response, lossless and many times larger. | compact |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the description's added value is the containment guarantee and the non-obvious rule that the area outline is omitted unless response_detail='geometry' — genuinely behavior-changing information. It stops short of covering rate limits, cost, or error behavior, so not a 5.
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?
Three sentences, front-loaded with the defining characteristic (strict containment), then differentiation, then a caveat. Every sentence carries distinct information; no filler.
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?
No output schema exists, but the schema's response_detail documentation covers return shapes and the description reinforces the geometry caveat. For a 10-param read-only tool this is nearly complete; only output field specifics and limit/pagination interplay are unstated.
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?
Schema coverage is 100%, so baseline is 3; the description still adds meaning by explaining the semantic consequence of response_detail on the returned outline, tying a parameter to observable output. Geometry selection trade-offs (polygon vs bbox vs center/radius) are left to the schema descriptions.
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?
States a specific verb and resource ('Find all POIs within a strict geographic boundary') and enumerates the three accepted geometry types. It explicitly distinguishes itself from tomtom-nearby and tomtom-poi-search, so an agent can route without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('when the search must be confined to a specific region') with concrete examples, and names both alternative tools plus the condition that selects them (radius vs location bias vs guaranteed-containment). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Visualize custom GeoJSON data on a TomTom basemap. The map is drawn by the MCP app, so the visual requires a client that supports MCP apps; the caller gets back only a summary. Intended for large datasets, heatmaps, cluster maps, choropleth maps, or GeoJSON data (from a URL or inline) rendered on a map. Supports markers, heatmaps, clusters, lines, polygon fills, and choropleth maps. Provide data via HTTPS URL or inline GeoJSON. Multiple layers can be overlaid in a single call. Point features are automatically enriched with TomTom address data when clicked (reverse geocode). Placing a few specific markers, routes, or polygons is handled by tomtom-dynamic-map; route calculations (directions, travel time) are handled by tomtom-routing.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Display title shown as an overlay on the map. Example: 'Store Locations'. | |
| layers | Yes | Array of layer configurations (max 10). Each layer defines how to visualize the data. Multiple layers can overlay different visualization types on the same data. Example: [{ type: 'heatmap' }, { type: 'markers', label_property: 'name' }]. | |
| geojson | No | Inline GeoJSON string. Must be a valid FeatureCollection or Feature object. Max 10MB. Mutually exclusive with 'data_url'. For larger datasets, host the file and use 'data_url' instead. | |
| show_ui | No | Render the data on the interactive MCP app map. The visualization is the tool's only output; set to false only to validate the data without a map. Default: true. | |
| data_url | No | HTTPS URL to fetch GeoJSON data from (server-side). Supports FeatureCollection or single Feature. Max 50MB, 30s timeout. Mutually exclusive with 'geojson'. Preferred for large datasets. Example: 'https://example.com/data.geojson'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely non-obvious behavior: rendering happens in the MCP app so the caller receives only a summary, a client-side capability requirement, automatic reverse-geocode enrichment of clicked points, and implicit size/timeout constraints. None of this contradicts the annotations.
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?
Front-loaded with purpose and alternatives, and each sentence carries information. Slight redundancy: the enumeration of markers/heatmaps/clusters/lines/polygons largely restates the layer type enum already documented in the schema.
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?
For a read-only rendering tool with no output schema, the description covers the essential non-schema facts an agent needs: client capability requirement, summary-only return, data source options and limits, and layer composability. Nothing critical is missing.
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?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the URL-vs-inline choice and multi-layer overlay semantics, but adds no syntax or behavioral detail beyond what the per-field descriptions already state.
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?
States a specific verb and resource ('Visualize custom GeoJSON data on a TomTom basemap') plus the supported visualization repertoire. It explicitly contrasts itself with tomtom-dynamic-map and tomtom-routing, so an agent can distinguish it from siblings without opening a schema.
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?
Gives positive guidance (large datasets, heatmaps, clusters, choropleths, URL or inline GeoJSON, multi-layer overlays) and explicit exclusions with named alternatives: few markers/routes/polygons → tomtom-dynamic-map, directions/travel time → tomtom-routing. Prerequisites (client must support MCP apps) are also disclosed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an interactive map with markers, drawn lines, polygons, and area overlays. The map is drawn by the MCP app, so the visual requires a client that supports MCP apps. The caller gets back only a summary (the view, marker positions, route distance and time), never route lines or area outlines; tools whose response_detail offers 'geometry' return those as GeoJSON. Intended for map visualization: showing locations on a map, highlighting areas, or combining multiple visual elements in one view. Not intended for route calculations (tomtom-routing), traffic incidents (tomtom-traffic), or large-dataset visualization like heatmaps/clusters/choropleth (tomtom-data-viz). The optional routePlans parameter can calculate and draw routes on the map; it is meant for routes combined with other map elements (markers, polygons) in a single view.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | Bounding box in format [west, south, east, north] (min longitude, min latitude, max longitude, max latitude). Alternative to center+zoom. Use this parameter to ensure all map elements are fully visible. EXAMPLE: [4.87, 52.355, 4.915, 52.385] for central Amsterdam area. | |
| zoom | No | Zoom level (0-22). EXAMPLES: 3 (continent), 6 (country), 10 (city), 15 (neighborhood), 18 (street), 20-22 (building detail). Without it the zoom fits the content (or the bbox). NOTE: Zoom levels 20+ are only useful for very small geographic areas. | |
| width | No | Map viewport width in pixels (100-2048), used to fit the initial framing. DEFAULT: 600. EXAMPLE: 800 for standard display, 1200 for a wider view. | |
| center | No | Map center coordinates. With 'zoom' it sets the view exactly; alone, the map centers here and zooms to fit the content. Ignored when 'bbox' is given. EXAMPLE: {lat: 52.3676, lon: 4.9041} for Amsterdam Central. | |
| height | No | Map viewport height in pixels (100-2048), used to fit the initial framing. DEFAULT: 400. EXAMPLE: 600 for standard display, 900 for a taller view. | |
| routes | No | Draw straight lines between coordinates — for visualizing custom paths, connections, or external data (e.g. flight paths, supply chains, hiking trails). These are NOT road-following routes and have no distance/time info. For actual driving or walking routes that follow roads, use 'routePlans' instead. EXAMPLE: [{points: [{lat: 52.3676, lon: 4.9041}, {lat: 52.36, lon: 4.8852}], color: '#0000FF', name: 'Flight Path'}]. | |
| markers | No | Array of markers to display on the map. Each marker can have custom color, label, and priority. EXAMPLE: [{lat: 52.3676, lon: 4.9041, color: '#FF4444', label: 'Amsterdam Central', priority: 'high'}]. | |
| show_ui | No | Render the map in the interactive MCP app (zoom, pan, click). The map is drawn by the app, so leaving this on is what makes the tool produce anything visual. Set to false only when the caller just wants the request acknowledged without a map. DEFAULT: true. | |
| polygons | No | Array of polygons and circles to display on the map. Supports both custom polygon shapes (with coordinate arrays) and circular areas (with center point and radius). Each shape can have custom styling and labels. EXAMPLE for polygon: [{type: 'polygon', coordinates: [[4.9041, 52.3676], [4.8979, 52.3745], [4.8852, 52.36], [4.9041, 52.3676]], fillColor: 'rgba(255,0,0,0.3)', label: 'Tourist Area'}]. EXAMPLE for circle: [{type: 'circle', center: {lat: 52.3676, lon: 4.9041}, radius: 1000, fillColor: 'rgba(0,0,255,0.2)', label: '1km Radius'}]. | |
| routePlans | No | Array of route calculations to draw on the map. Each entry is an independent origin→destination trip calculated via TomTom Routing API. NOTE: For standalone route queries (directions, travel time, distance), prefer the tomtom-routing tool instead. Use routePlans here only when you need to visualize calculated routes alongside other map elements (markers, polygons) in a single map. Each plan can have its own routeType, travelMode, and color. EXAMPLE: [{origin: {lat: 52.37, lon: 4.89}, destination: {lat: 52.36, lon: 4.89}, label: 'Morning Commute'}, {origin: {lat: 48.86, lon: 2.35}, destination: {lat: 48.85, lon: 2.29}, label: 'Paris Tour'}]. | |
| showLabels | No | Whether to show text labels on markers, routes, and polygons. DEFAULT: false. EXAMPLE: true to display all labels. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds crucial context annotations cannot: the map is rendered by the MCP app and requires an app-capable client, and the caller receives only a summary (view, positions, distance/time), not geometry. It even points to response_detail='geometry' on other tools for GeoJSON. The only minor omission is any note on error/fallback behavior when the client lacks app support.
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?
Front-loaded with the core purpose and the client-requirement caveat before the when-to-use guidance. Sentences are dense but each carries distinct information; the routePlans paragraph is slightly long relative to its weight but not wasteful.
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?
For an 11-parameter tool with nested objects and no output schema, the description correctly explains what the caller receives (a summary, not geometry) and why a client must support MCP apps. That covers the critical gaps; only minor edge cases like failure behavior for unsupported clients are unaddressed.
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?
Schema description coverage is 100% with richly documented, example-laden parameters, so the schema carries parameter meaning and baseline 3 applies. The description does add conceptual distinctions (routes are straight lines, not road-following; routePlans computes real routes for combined views), but that is marginal added value over the already complete schema.
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?
Specific verb (render) plus resource (interactive map) and the exact element types supported (markers, lines, polygons, area overlays). It explicitly distinguishes itself from tomtom-routing, tomtom-traffic, and tomtom-data-viz by name, so an agent can route among siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States intended uses (showing locations, highlighting areas, combining elements in one view) and explicit exclusions for routing, traffic, and large-dataset visualization, each paired with the sibling tool to use instead. It also resolves the subtle routePlans-vs-tomtom-routing overlap with a clear condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find EV charging stations with their connector types and power levels. Results carry no real-time charger availability.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (1-100). Default: 10. | |
| query | No | Search query for EV charging stations. Can be a station name or brand (e.g., 'Tesla Supercharger', 'ChargePoint'). Leave empty to find all nearby stations. | |
| cursor | No | The next page of results: the nextCursor of the previous response, with the same other parameters. | |
| radius | No | Search radius in meters. Without it, results are biased toward position with no distance limit. Examples: 1000 (walking), 5000 (local), 20000 (wide area). | |
| show_ui | No | Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false | |
| language | No | Language for results (IETF tag). Examples: 'en-US', 'de-DE', 'fr-FR'. | |
| position | Yes | Center position as [longitude, latitude] for EV station search (GeoJSON convention). Required for location-based results. Example: [4.89707, 52.377956] for Amsterdam. | |
| countries | No | Limit results to countries (ISO alpha-2 codes). Example: ['US'], ['DE', 'FR']. | |
| minPowerKW | No | Minimum charging power in kW. Examples: 7 (slow AC), 22 (fast AC), 50 (DC fast), 150 (ultra-fast DC). | |
| connectorTypes | No | Filter by EV connector types: 'IEC62196Type2CableAttached' is Type 2/Mennekes, 'IEC62196Type2CCS' CCS2, 'IEC62196Type1CCS' CCS1, 'IEC62196Type1' Type 1/J1772, 'StandardHouseholdCountrySpecific' a domestic plug. | |
| response_detail | No | Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger. | compact |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds a genuinely useful caveat beyond that: results carry no real-time charger availability, which prevents an agent from over-promising live status. It does not mention pagination or the compact/full default, but that is documented in the schema.
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?
Two sentences, zero waste, with the core capability front-loaded and the limitation immediately after. Nothing is repeated from the schema or annotations.
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?
For an 11-parameter open-world search tool the description is thin: it never mentions the required position/GeoJSON convention, radius behavior, or paging, and it gives no routing guidance among the many sibling search tools. Those gaps are partly absorbed by the very rich schema and annotations, so it is adequate but not complete.
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?
Schema description coverage is 100% and every parameter, including enum values and examples for connectorTypes and minPowerKW, is documented in the schema itself. The description adds no parameter meaning beyond that, so the baseline 3 applies.
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?
The description states a specific verb and resource (find EV charging stations) plus what the results contain (connector types, power levels). It implicitly separates itself from generic search siblings by naming EV charging as the domain, though it never names an alternative tool explicitly.
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?
Usage is only implied: an agent can infer it should call this when the task involves EV chargers rather than general POIs. There is no explicit when-to-use, when-not-to-use, or pointer to siblings like tomtom-poi-search or tomtom-nearby for non-EV searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Typo-tolerant search for addresses, points of interest, and geographies.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | Geopolitical view for disputed territories. | |
| limit | No | Maximum number of results to return (1-100). Default: 10. | |
| 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' | |
| cursor | No | The next page of results: the nextCursor of the previous response, with the same other parameters. | |
| idxSet | No | Search only these indexes, comma-separated: 'Geo' (geographies), 'PAD' (point addresses), 'Addr' (address ranges), 'Str' (streets), 'XStr' (cross streets), 'POI'. | |
| radius | No | Search radius in meters around position; needs position. Examples: 1000 (neighborhood), 5000 (city area), 20000 (metro area). | |
| fuelSet | No | Fuel types, comma-separated: Petrol, LPG, Diesel, Biodiesel, DieselForCommercialVehicles, E85, LNG, CNG, Hydrogen, AdBlue. | |
| show_ui | No | Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false | |
| brandSet | No | Filter by brand names, comma-separated. Examples: 'Starbucks', 'Marriott,Hilton'. | |
| language | No | Preferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES' | |
| 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). | |
| position | No | Center position as [longitude, latitude] for location bias (GeoJSON convention). Example: [4.89707, 52.377956] for Amsterdam. Not with boundingBox. | |
| 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 | |
| countries | No | Limit results to specific countries using ISO alpha-2 codes. Example: ['US'], ['FR', 'GB'], ['NL', 'DE'] | |
| typeahead | No | Enable autocomplete mode for partial queries. Use for search-as-you-type interfaces. | |
| maxPowerKW | No | Maximum charging power in kW for EV stations | |
| minPowerKW | No | Minimum charging power in kW for EV stations | |
| boundingBox | No | Bounding box as [minLon, minLat, maxLon, maxLat] (GeoJSON convention). Example: [4.8, 52.3, 4.95, 52.45] for Amsterdam area. Not with position. | |
| relatedPois | No | Include related points of interest: 'off', 'child', 'parent' or 'all'. Default: 'off'. | |
| connectorSet | No | EV connector types, comma-separated. Examples: 'IEC62196Type2CCS', 'IEC62196Type2CableAttached,Chademo', 'Tesla'. | |
| 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 | |
| entityTypeSet | No | Filter results by geographic entity types, comma-separated: Country, CountrySubdivision, CountrySecondarySubdivision, CountryTertiarySubdivision, Municipality, MunicipalitySubdivision, MunicipalitySecondarySubdivision, Neighbourhood, PostalCodeArea. Note: This parameter is for geographic entities only, not POIs. For POI filtering, use poiCategories instead | |
| maxFuzzyLevel | No | Maximum fuzzy matching level (1-4) | |
| minFuzzyLevel | No | Minimum fuzzy matching level (1-4) | |
| poiCategories | No | Filter POI results by UPPER_SNAKE_CASE text category codes (e.g. 'RESTAURANT', 'PARKING_GARAGE'), NOT numeric IDs. IMPORTANT: Never guess codes — always call tomtom-poi-categories first with the user's intent as keywords to discover valid codes. | |
| response_detail | No | Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger. | compact |
| extendedPostalCodesFor | No | Comma-separated index types whose results carry extended postal codes: Geo, PAD, Addr, Str, XStr, and POI for POI results. Default: every type except Geo, so listing types removes the codes from the others. Examples: 'PAD,Addr', 'Geo'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, so the safety profile is fully covered elsewhere. The description adds no further behavioral context such as pagination behavior, the compact-vs-full response tradeoff, or the show_ui widget limitation, which are non-obvious traits an agent would benefit from knowing up front.
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?
The sentence is clean, front-loaded, and waste-free, but for a 27-parameter tool it reads as under-specification rather than disciplined brevity. It is not padded, yet it leaves the definition too thin to stand on.
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?
A 27-param search tool with no output schema and an entirely self-describing schema means most calling details are covered structurally, and readOnly annotations carry the safety story. The remaining gap is disambiguation from the many overlapping TomTom search siblings, which a one-line description cannot supply.
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?
Schema coverage is 100% and the 27 parameter descriptions are unusually rich, including enum values, examples, mutual exclusions (position vs boundingBox), and even cross-tool routing for poiCategories. The one-line description adds nothing beyond that, so the baseline 3 applies.
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?
States a specific verb and resource set (search addresses, POIs, geographies) and the 'typo-tolerant' qualifier distinguishes it from exact-match geocoding. However, it never names or contrasts with obvious siblings like tomtom-geocode, tomtom-poi-search, or tomtom-area-search, so the agent must infer the boundary.
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?
There is no when-to-use or when-not guidance and no mention of alternatives, despite a crowded sibling set (geocode, poi-search, nearby, area-search, ev-search) where routing matters a lot. The single sentence describes what it is, not when to pick it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert street addresses to coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | Geopolitical view for disputed territories. | |
| limit | No | Maximum number of results to return (1-100). Default: 10. | |
| 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' | |
| cursor | No | The next page of results: the nextCursor of the previous response, with the same other parameters. | |
| radius | No | Search radius in meters around position; needs position. | |
| show_ui | No | Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false | |
| language | No | Preferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES' | |
| 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). | |
| position | No | Center position as [longitude, latitude] for location bias (GeoJSON convention). Example: [4.89707, 52.377956] for Amsterdam. Not with boundingBox. | |
| countries | No | Limit results to specific countries using ISO alpha-2 codes. Example: ['US'], ['FR', 'GB'], ['NL', 'DE'] | |
| boundingBox | No | Bounding box as [minLon, minLat, maxLon, maxLat] (GeoJSON convention). Example: [4.8, 52.3, 4.95, 52.45] for Amsterdam area. Not with position. | |
| entityTypeSet | No | Filter results by geographic entity types, comma-separated: Country, CountrySubdivision, CountrySecondarySubdivision, CountryTertiarySubdivision, Municipality, MunicipalitySubdivision, MunicipalitySecondarySubdivision, Neighbourhood, PostalCodeArea. Note: This parameter is for geographic entities only, not POIs. For POI filtering, use poiCategories instead | |
| response_detail | No | Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger. | compact |
| extendedPostalCodesFor | No | Comma-separated index types whose results carry extended postal codes: Geo, PAD, Addr, Str, XStr, and POI for POI results. Default: every type except Geo, so listing types removes the codes from the others. Examples: 'PAD,Addr', 'Geo'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds no behavioral context beyond what the annotations already establish, such as rate limits, pagination, or what happens with ambiguous addresses.
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?
The single sentence is front-loaded and free of waste. It is arguably under-specified for a 14-parameter tool, but it is concise and direct, not bloated.
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?
For a complex geocoding tool with 14 parameters and no output schema, the description is too thin. It omits return-shape information, usage context, and guidance on when to use this versus related search tools, leaving the schema and annotations to carry nearly all the burden.
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?
With 14 parameters and 100% schema description coverage, the schema itself fully documents each parameter with examples and constraints. The description contributes no parameter-level meaning beyond the obvious 'address' input, so the baseline 3 is appropriate.
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?
The description states a specific verb+resource ('convert street addresses to coordinates'), so the core purpose is clear. However, it does not explicitly distinguish this tool from siblings like tomtom-reverse-geocode or tomtom-fuzzy-search, leaving differentiation to be inferred.
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?
It offers no when-to-use guidance, exclusions, or references to alternative tools. An agent must infer from the name and schema that this is for forward geocoding and not for coordinate-to-address lookup or POI search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Internal tool for apps to retrieve the TomTom API key
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description's 'retrieve' is consistent with those. It adds the 'internal' access context but does not disclose operational details such as authentication requirements or secret-handling expectations.
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?
One concise sentence names the caller, action, and resource with no filler, repetition, or unnecessary detail.
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?
For a zero-parameter, read-only, idempotent internal lookup, the description covers the essential context. It is slightly incomplete because there is no output schema and no mention of failure behavior if the key is missing or how the key should be handled in responses.
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?
The tool has zero parameters and 100% schema description coverage, so there is no parameter burden for the description to carry. The baseline 4 applies because no parameter ambiguity exists.
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?
The description names a specific verb ('retrieve'), a specific resource ('TomTom API key'), and an intended caller ('apps'). It is clearly distinguishable from sibling tools like tomtom-get-app-config and tomtom-get-viz-data.
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?
The phrase 'Internal tool for apps' provides clear context that this is a back-end credential lookup for applications rather than a general-purpose utility. It does not explicitly name alternatives, but no sibling tool appears to serve this same key-retrieval role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Internal tool for apps to retrieve client configuration such as the attribution user-agent
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, lowering the burden. The description adds useful context by labeling the tool 'internal' and giving an example of returned content, going slightly beyond the structured annotations. No contradiction with annotations.
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?
The description is a single sentence that is front-loaded with the action and resource and includes a concrete example. No filler, redundancy, or unnecessary detail.
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?
With no output schema and no parameters, the description must carry the burden of indicating what the tool returns. The example ('attribution user-agent') hints at the output payload, and while the full set of config fields isn't enumerated, it is adequate for a simple no-arg config getter.
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?
The tool takes zero parameters and schema coverage is 100%, so there are no parameter semantics to document. The description correctly focuses on purpose rather than parameters, meeting the baseline for zero-parameter tools.
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?
Description states a specific verb ('retrieve') and resource ('client configuration') with a concrete example ('attribution user-agent'). It is clearly distinct from geocoding/routing/map siblings, but it does not explicitly differentiate from other internal config tools like get-api-key or get-viz-data.
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?
The description implies usage for apps needing client configuration, but provides no explicit when/when-not guidance or alternatives. The 'Internal tool for apps' context is present, yet no exclusions or sibling comparisons are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Internal tool for the data-viz app to get data missing from the result, by running tomtom-data-viz again
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | The tool whose result the app draws, from the result's _meta.tool | |
| reason | Yes | Why the app fetches: the result had no inline app data, or it failed to decode | |
| arguments | Yes | That tool call's arguments |
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. The description adds that the tool reruns tomtom-data-viz, which is useful behavioral context, but it does not discuss return behavior, permissions, or rate limits.
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?
The description is a single tight sentence with no filler. Each clause contributes useful context: internal scope, target app, missing-data purpose, and rerun mechanism.
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?
The annotations and schema cover safety and parameters well, but with no output schema the description does not explain what data is returned or how the rerun result is shaped. It is adequate but leaves return-value context implicit.
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?
Schema description coverage is 100%, so the schema already documents all three parameters, including the reason enum and the nested arguments object. The description adds no parameter-level detail beyond the schema, so the baseline of 3 is appropriate.
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?
The description states a specific operation: getting data missing from a result by rerunning tomtom-data-viz. It distinguishes this internal retrieval path from the broader tomtom-data-viz sibling, though the phrase “get data missing” remains somewhat internal-app-specific.
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?
It gives clear usage context: this is an internal tool for the data-viz app and is used when data is missing from a result. It does not spell out when-not conditions or alternatives, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find places of a kind close to a specific point. Best for 'what's around here?' queries when you have exact coordinates (lat/lon). Needs poiCategories, or a brand, fuel, connector or charging-power filter. Returns results sorted by distance. Use tomtom-area-search instead when the search area is a polygon or bounding box rather than a simple radius.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | Geopolitical view for disputed territories. | |
| limit | No | Maximum number of results to return (1-100). Default: 20. | |
| cursor | No | The next page of results: the nextCursor of the previous response, with the same other parameters. | |
| radius | No | Search radius in meters. Default: 1000. Recommended: 500 (walking), 1000 (local), 5000 (driving), 20000 (wide area). | |
| fuelSet | No | Fuel types, comma-separated: Petrol, LPG, Diesel, Biodiesel, DieselForCommercialVehicles, E85, LNG, CNG, Hydrogen, AdBlue. | |
| show_ui | No | Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false | |
| brandSet | No | Filter by brand names, comma-separated. Examples: 'Starbucks', 'Marriott,Hilton'. | |
| language | No | Preferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES' | |
| 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). | |
| position | Yes | Center position as [longitude, latitude] for nearby search (GeoJSON convention). Example: [4.89707, 52.377956] for Amsterdam. Use precise coordinates from geocoding. | |
| 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 | |
| countries | No | Limit results to specific countries using ISO alpha-2 codes. Example: ['US'], ['FR', 'GB'], ['NL', 'DE'] | |
| maxPowerKW | No | Maximum charging power in kW for EV stations | |
| minPowerKW | No | Minimum charging power in kW for EV stations | |
| relatedPois | No | Include related points of interest: 'off', 'child', 'parent' or 'all'. Default: 'off'. | |
| connectorSet | No | EV connector types, comma-separated. Examples: 'IEC62196Type2CCS', 'IEC62196Type2CableAttached,Chademo', 'Tesla'. | |
| 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 | |
| poiCategories | No | POI categories to find, as UPPER_SNAKE_CASE codes (e.g. 'RESTAURANT', 'PARKING_GARAGE'), NOT numeric IDs. Required unless brandSet, connectorSet, fuelSet, minPowerKW or maxPowerKW is given. IMPORTANT: Never guess codes — always call tomtom-poi-categories first with the user's intent as keywords to discover valid codes. | |
| response_detail | No | Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger. | compact |
| extendedPostalCodesFor | No | Comma-separated index types whose results carry extended postal codes: Geo, PAD, Addr, Str, XStr, and POI for POI results. Default: every type except Geo, so listing types removes the codes from the others. Examples: 'PAD,Addr', 'Geo'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description correctly spends its words elsewhere: it discloses that results are distance-sorted and that the filter fields form an OR-requirement. It stops short of describing pagination (the cursor/limit interplay) or result-size tradeoffs.
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?
Four short sentences, front-loaded with purpose and query shape before prerequisites and the sibling alternative. Every clause carries routing or requirement information; nothing is padding.
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?
A 20-parameter tool with no output schema, yet the description covers purpose, precondition, ordering of results, and the alternative tool. Remaining gaps (pagination, compact vs full response size) are documented in the schema, so the definition is nearly complete for correct invocation.
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?
Schema coverage is 100% and the schema itself already carries the nuanced notes (the poiCategories-vs-filter disjunction, the 'call tomtom-poi-categories first' warning, radius presets). The description echoes the requirement rather than adding syntax or format detail beyond it, so the baseline 3 applies.
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?
Opens with a specific verb+resource ('Find places of a kind close to a specific point') and immediately distinguishes itself from tomtom-area-search by geometry (radius vs polygon/bbox). An agent can route between the two without opening either schema.
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?
States the ideal query shape ('what's around here?' with exact lat/lon), the precondition (needs poiCategories or a brand/fuel/connector/power filter), and an explicit when-not rule naming the alternative sibling. This is the full when/how/exclusion set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up POI category codes from natural language. The poiCategories parameter of the search tools accepts only codes returned by this tool. Category codes are UPPER_SNAKE_CASE text strings (e.g. 'ITALIAN_RESTAURANT', 'PARKING_GARAGE'), not numeric IDs. Workflow: (1) extract the user's intent as keywords (e.g. 'italian restaurants in Amsterdam' → filters: ['italian restaurant']); (2) call this tool with those keywords in the filters parameter; (3) pass the returned category codes in the poiCategories parameter of search tools (fuzzy-search, poi-search, nearby, area-search). Guessed or hardcoded category codes are unreliable; this tool is the source of valid codes.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | Keywords to find categories by name or synonym, accents ignored. Each keyword returns its best-matching categories, so 'bar' finds Bar and not Nail Salon; with several keywords, each one's best match comes first. Examples: ['gym'], ['italian restaurant'], ['parking', 'garage']. Omit to return all available POI categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: the output is textual category codes, and the tool is the authoritative source of valid codes. It stops short of describing response shape or any rate-limit/auth considerations.
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?
Front-loads the core purpose and code-format constraint before the workflow, and every sentence carries actionable information. Slightly long, but the emphasis on code format and unreliability of guesses is justified for a lookup tool feeding downstream parameters.
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?
There is no output schema, and the description covers the essentials an agent needs: what comes back (category codes), how to feed them into the search tools, and what happens when filters is omitted. A brief note on the response structure (e.g., whether category names accompany codes) would make it complete.
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?
Schema coverage is 100%, so the filters parameter is already well documented, including the 'omit to return all categories' behavior. The description still adds value by explaining how to derive filters from natural-language intent with a concrete example, going beyond the schema's keyword-matching note.
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?
States a specific verb ('look up') and resource ('POI category codes') and explains that the codes are UPPER_SNAKE_CASE strings rather than numeric IDs. It clearly distinguishes itself from the search siblings by positioning itself as the source of the poiCategories values they consume.
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?
Provides an explicit numbered workflow (extract keywords → call this tool → pass codes to search tools) and names the concrete alternatives that consume the output (fuzzy-search, poi-search, nearby, area-search). It also states the negative case: guessed or hardcoded codes are unreliable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a specific business or POI by name, or browse an entire POI category. Best for finding a known place (e.g. 'Starbucks') or listing all businesses of a type (e.g. the 'ITALIAN_RESTAURANT' category code from tomtom-poi-categories). Supports optional location bias but does not constrain results to a strict geographic boundary — tomtom-area-search does that.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | Geopolitical view for disputed territories. | |
| limit | No | Maximum number of results to return (1-100). Default: 10. | |
| query | Yes | Name of the POI to search for. If the intended query is a POI category like 'restaurant', provide an empty string for this param and use the category filter parameter to apply the desired category filter. | |
| cursor | No | The next page of results: the nextCursor of the previous response, with the same other parameters. | |
| radius | No | Search radius in meters around position; needs position. Examples: 1000 (walking), 5000 (driving), 20000 (wide area). | |
| fuelSet | No | Fuel types, comma-separated: Petrol, LPG, Diesel, Biodiesel, DieselForCommercialVehicles, E85, LNG, CNG, Hydrogen, AdBlue. | |
| show_ui | No | Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false | |
| brandSet | No | Filter by brand names, comma-separated. Examples: 'Starbucks', 'Marriott,Hilton'. | |
| language | No | Preferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES' | |
| 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). | |
| position | No | Center position as [longitude, latitude] for location bias (GeoJSON convention). Example: [4.89707, 52.377956] for Amsterdam. Not with boundingBox. | |
| 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 | |
| countries | No | Limit results to specific countries using ISO alpha-2 codes. Example: ['US'], ['FR', 'GB'], ['NL', 'DE'] | |
| typeahead | No | Autocomplete mode for partial queries. Use for search interfaces. | |
| maxPowerKW | No | Maximum charging power in kW for EV stations | |
| minPowerKW | No | Minimum charging power in kW for EV stations | |
| boundingBox | No | Bounding box as [minLon, minLat, maxLon, maxLat] (GeoJSON convention). Example: [4.8, 52.3, 4.95, 52.45] for Amsterdam area. Not with position. | |
| relatedPois | No | Include related points of interest: 'off', 'child', 'parent' or 'all'. Default: 'off'. | |
| connectorSet | No | EV connector types, comma-separated. Examples: 'IEC62196Type2CCS', 'IEC62196Type2CableAttached,Chademo', 'Tesla'. | |
| 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 | |
| poiCategories | No | Filter POI results by UPPER_SNAKE_CASE text category codes (e.g. 'RESTAURANT', 'PARKING_GARAGE'), NOT numeric IDs. IMPORTANT: Never guess codes — always call tomtom-poi-categories first with the user's intent as keywords to discover valid codes. | |
| response_detail | No | Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger. | compact |
| extendedPostalCodesFor | No | Comma-separated index types whose results carry extended postal codes: Geo, PAD, Addr, Str, XStr, and POI for POI results. Default: every type except Geo, so listing types removes the codes from the others. Examples: 'PAD,Addr', 'Geo'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: position only biases results and does not constrain them to a boundary, and category codes must be discovered first rather than guessed. Pagination/rate behavior is left to the schema's cursor parameter.
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?
Two sentences, front-loaded with what the tool does, followed by usage and the key constraint. Every clause carries information; nothing is repeated from the schema.
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?
For a 23-parameter open-world search tool with no output schema, the description covers purpose, mode selection, the sibling alternative, and the bias-vs-boundary behavior well. It does not mention the compact/full response detail choice or the map widget toggle, though both are fully documented in the schema, so the gap is minor.
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?
Schema description coverage is 100%, so the schema already documents all 23 parameters in detail, including enum values and format examples. The description adds only the query-vs-category interaction nuance, which the schema duplicates. Baseline 3 is appropriate when the schema does the heavy lifting.
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?
States a specific verb and resource (search for a business/POI) plus the two supported modes: name lookup and category browsing. It explicitly distinguishes itself from tomtom-area-search, so an agent can route between them without opening either schema.
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?
Gives clear context for when to use it ('finding a known place' vs 'listing all businesses of a type') and names tomtom-area-search as the alternative for strict geographic boundaries. It also points at tomtom-poi-categories for category codes. It does not disambiguate from other overlapping siblings such as tomtom-fuzzy-search, tomtom-nearby, or tomtom-ev-search, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Internal tool for apps to report whether they drew their data
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | The tool whose result the app draws | |
| error | No | ||
| stage | No | Where a failure happened | |
| source | No | Where the drawn data came from | |
| status | Yes | ||
| duration_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word "report" implies the app submits status information, which is a state-changing write, while the annotations declare readOnlyHint=true and destructiveHint=false. That is a direct conflict, so the description contradicts the structured safety metadata rather than supplementing it.
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?
The description is a single front-loaded sentence with no filler. It is concise, though its brevity contributes to the gaps in usage and parameter detail.
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?
For a six-parameter reporting tool with no output schema, the description is too sparse. It omits the reporting workflow, expected status values, failure semantics, and how the optional fields should be populated.
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?
The description mentions no parameters at all, despite six parameters and only 50% schema description coverage. It does not clarify the meaning of status, stage, source, error, duration_ms, or how they relate to a failed draw.
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?
The description names a specific verb and resource: apps report whether they drew their data. It also identifies the tool as internal, which distinguishes it from the public search/geocode/routing siblings, though "drew their data" remains somewhat jargon-like.
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?
It implies usage by apps reporting draw status, likely after a data/draw cycle, but does not state when to call it versus alternatives or when not to call it. There is no explicit routing guidance among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert coordinates to addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | Geopolitical view for disputed territories. | |
| radius | No | Search radius in meters. Default: 100 | |
| heading | No | Heading direction in degrees (0-360) for improved accuracy on roads | |
| show_ui | No | Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false | |
| language | No | Preferred language for results using IETF language tags. Examples: 'en-US', 'fr-FR', 'de-DE', 'es-ES' | |
| position | Yes | Position as [longitude, latitude] to reverse geocode (GeoJSON convention). Precision to 4+ decimal places recommended. Example: [4.89707, 52.377956]. | |
| entityType | No | Filter by geography entity types, comma-separated: Country, CountrySubdivision, CountrySecondarySubdivision, CountryTertiarySubdivision, Municipality, MunicipalitySubdivision, MunicipalitySecondarySubdivision, Neighbourhood, PostalCodeArea. Not with heading, which the API then ignores. | |
| response_detail | No | Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger. | compact |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds no behavioral context beyond that – nothing about the entityType/heading conflict, the interactive widget (show_ui), or response size differences (response_detail), all of which meaningfully change behavior.
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?
A single, front-loaded sentence with zero waste. It is arguably under-specified rather than padded, so it earns high marks on conciseness alone.
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?
For an eight-parameter tool with no output schema, the description is thin, but the rich annotations and fully documented schema compensate for most of the gap. An agent can still call it correctly by reading the schema.
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?
Schema description coverage is 100%, so all eight parameters, including enums, defaults, and the entityType/heading interaction, are already documented in the schema. The description contributes nothing extra, which is the expected baseline when the schema does the heavy lifting.
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?
States a specific verb ('Convert') and resource ('coordinates to addresses'), which is clear and actionable. It does not explicitly distinguish itself from the inverse sibling tomtom-geocode, so it falls short of a 5.
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?
There is no guidance on when to use this tool versus tomtom-geocode (the reverse direction) or the search tools, and no mention of prerequisites or exclusions. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate optimal routes through an ordered list of locations [origin, ...stops, destination]. The primary tool for directions, routes, travel time, or distance between places — whether a simple A-to-B or a multi-stop itinerary (e.g. 'route from Amsterdam to Berlin', 'drive from A to B via C and D'). Returns distance, travel time and traffic delay, with a summary per leg. Turn-by-turn instructions are not available. Route polylines are omitted unless response_detail is 'geometry'.
| Name | Required | Description | Default |
|---|---|---|---|
| avoid | No | Route features to avoid. May increase travel time. | |
| show_ui | No | Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false | |
| traffic | No | Traffic consideration: 'live' (real-time + historical), 'historical' (historical only). | |
| 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. | |
| locations | Yes | Ordered list of coordinates [origin, ...intermediateStops, destination]. Minimum 2 (origin + destination); add intermediate positions for multi-stop routes. Use geocoding for accurate coordinates. | |
| routeType | No | Route optimization: 'fast' (time-optimized), 'short' (distance-optimized), 'efficient' (fuel-efficient), 'thrilling' (scenic). Default: 'fast'. | |
| travelMode | No | Transportation mode. Default: 'car'. | |
| sectionType | No | Keep only these section types in the route, besides leg. Default: all types the route has. Compact responses drop the map-rendering types (urban, tunnel, motorway, lowEmissionZone, pedestrian, speedLimit, roadShields, vehicleRestricted); they appear only with response_detail 'full'. | |
| vehicleWeight | No | Vehicle weight in kg. | |
| vehicleHeading | No | Heading of the vehicle at the origin, in degrees clockwise from north (0-359), for a route that starts in the direction of travel. | |
| maxAlternatives | No | Number of alternative routes (0-5). More alternatives = more options but larger response. | |
| response_detail | No | Response detail level. 'compact' (default): essential fields and point coordinates, no geometry. 'geometry': compact plus a 'geometry' key holding a GeoJSON FeatureCollection ([lon, lat], at most 1,000 vertices per feature); use this to get coordinates to draw or process. 'full': the raw API response, lossless and many times larger. | compact |
| vehicleMaxSpeed | No | Maximum vehicle speed in km/h for commercial routing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description goes further by describing what comes back (distance, travel time, traffic delay, per-leg summary) and the important gating that polylines are omitted unless response_detail='geometry'. It does not cover cost, rate limits, or failure behavior, so it earns a 4 rather than a 5.
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?
Four compact sentences, front-loaded with the core verb and resource, then usage contexts, then return shape, then the key limitation and gating flag. No restatement of the title or schema, and every sentence carries actionable information.
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?
With 14 parameters and no output schema, the description correctly compensates by summarizing the return payload and the geometry/compact/full detail levels, which is the main risk area for an agent. Minor gaps remain around deprecated/exclusive parameters and traffic-mode selection, but nothing an agent needs to invoke it correctly is missing.
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?
Schema description coverage is 100%, so the schema already documents every parameter's format, enums, and defaults. The description reinforces the ordering semantics of locations and explains the response_detail trade-off, but adds little else (e.g. no guidance on when to set traffic='live' vs 'historical' or on maxAlternatives). Baseline 3 is appropriate when the schema does the heavy lifting.
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?
States a specific verb and resource ('Calculate optimal routes through an ordered list of locations') and explicitly positions itself as 'the primary tool for directions, routes, travel time, or distance between places.' This clearly separates it from siblings like tomtom-geocode, tomtom-traffic, and tomtom-search-along-route without requiring the agent to open any schema.
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?
Gives concrete invocation contexts, including example utterances ('route from Amsterdam to Berlin', 'drive from A to B via C and D') and the A-to-B vs multi-stop distinction. It also sets a boundary with 'Turn-by-turn instructions are not available.' It stops short of naming which sibling to use instead for geocoding or traffic-only queries, so routing guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find points of interest (restaurants, gas stations, hotels, etc.) along a route corridor. Calculates the route between origin and destination, then searches for POIs within a configurable distance from the route. The route line is omitted unless response_detail is 'geometry'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of POI results (1-100). Default: 10. | |
| query | Yes | What to search for along the route. Examples: 'gas station', 'restaurant', 'coffee', 'hotel', 'EV charging'. | |
| origin | Yes | Route starting point as [longitude, latitude] (GeoJSON convention). Use precise coordinates from geocoding. Example: [4.89707, 52.377956]. | |
| show_ui | No | Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false | |
| language | No | Language for results (IETF tag). Examples: 'en-US', 'de-DE'. | |
| routeType | No | Route optimization for the base route: 'fast', 'short', 'efficient' or 'thrilling'. Default: 'fast'. | |
| destination | Yes | Route ending point as [longitude, latitude] (GeoJSON convention). Use precise coordinates from geocoding. Example: [13.404954, 52.520008]. | |
| corridorWidth | No | Search corridor width in meters from the route centerline. Default: 5000 (5km). Smaller values = closer to route. | |
| poiCategories | No | Filter POI results by UPPER_SNAKE_CASE text category codes (e.g. 'RESTAURANT', 'PARKING_GARAGE'), NOT numeric IDs. IMPORTANT: Never guess codes — always call tomtom-poi-categories first with the user's intent as keywords to discover valid codes. | |
| response_detail | No | Response detail level. 'compact' (default): essential fields and point coordinates, no geometry. 'geometry': compact plus a 'geometry' key holding a GeoJSON FeatureCollection ([lon, lat], at most 1,000 vertices per feature); use this to get coordinates to draw or process. 'full': the raw API response, lossless and many times larger. | compact |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnly/idempotent/openWorld/destructive=false, so the safety profile is covered. The description adds real behavioral context beyond that: the route line is omitted by default, and response_detail='full' is 'many times larger', which warns about payload size. No statement about rate limits or auth needs, but for a read-only search that is minor.
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?
Three sentences, front-loaded with the action, then the mechanism, then the output caveat. Nothing redundant; each sentence carries distinct information.
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?
For a 10-parameter, no-output-schema tool, the description plus the fully documented schema cover what an agent needs to invoke it correctly. A small gap remains: it doesn't restate the required geocoded coordinate prerequisite or hint at result ordering/pagination, though the schema covers the coordinate format.
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?
Schema coverage is 100%, so baseline is 3. The description earns the extra point by crossing parameter boundaries: it links response_detail='geometry' to the presence of the route line, explaining the practical consequence of an enum choice rather than just restating the schema.
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?
States a specific verb and resource ('Find points of interest... along a route corridor') and immediately explains the mechanism (route between origin and destination, then POI search within a buffer). This clearly distinguishes it from the point-based siblings like tomtom-nearby, tomtom-poi-search, and tomtom-area-search.
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?
The 'along a route corridor' framing makes the selection condition implicit against point/area search siblings, and the description routes the agent through a prerequisite workflow for categories via tomtom-poi-categories. It stops short of explicitly naming the alternative tools or stating when-not to use this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find traffic incidents in an area. The primary tool for questions about traffic, accidents, road closures, congestion, or dangerous road conditions. Returns severity, description, delay and affected roads for each incident. Incident locations are omitted unless response_detail is 'geometry'.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | Yes | Bounding box as [minLon, minLat, maxLon, maxLat] (GeoJSON convention). Example: [-74.02, 40.70, -73.96, 40.80] for lower Manhattan. Use smaller areas for better results. | |
| show_ui | No | Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false | |
| language | No | Language for incident descriptions: 'en-GB', 'de-DE', 'fr-FR', 'es-ES'. Default: 'en-GB'. | |
| maxResults | No | Maximum number of incidents to return (1-1000). Default: 100. When more incidents match, the most severe are returned and the response includes an incidentSummary with full totals. | |
| categoryFilter | No | Incident categories to return. Default: all categories. | |
| response_detail | No | Response detail level. 'compact' (default): essential fields and point coordinates, no geometry. 'geometry': compact plus a 'geometry' key holding a GeoJSON FeatureCollection ([lon, lat], at most 1,000 vertices per feature); use this to get coordinates to draw or process. 'full': the raw API response, lossless and many times larger. | compact |
| timeValidityFilter | No | Which incidents to return by time: 'present' (happening now), 'future' (planned, e.g. road works). Default: ['present']. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds real value by naming the returned incident fields and, importantly, warning that incident locations are omitted unless response_detail is 'geometry' – a non-obvious behavior. It omits auth/rate-limit and pagination behavior, so 3 is appropriate.
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?
Three short sentences, front-loaded with the action and selection criteria, then the return shape and the one caveat. Every sentence carries distinct information with no redundancy.
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?
With no output schema, the description usefully previews returned fields (severity, description, delay, affected roads) and explains the geometry caveat, which is enough for correct invocation. It does not address bounding-box sizing strategy or result-volume expectations beyond what the schema covers.
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?
Schema coverage is 100% and each parameter carries a detailed description, so the schema does the heavy lifting. The description reinforces the response_detail/geometry dependency but adds no syntax or format detail beyond the schema, matching the baseline 3.
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?
States a specific verb and resource ('Find traffic incidents in an area') and frames itself as the primary traffic tool, which clearly separates it from the geocoding, search, and routing siblings. It does not name an explicit alternative, so a 4 rather than a 5.
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?
Explicitly enumerates the question types that should route here ('traffic, accidents, road closures, congestion, or dangerous road conditions'), giving strong positive selection guidance. No when-not/exclusion guidance is given, which keeps it at 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.6.14tomtom-get-app-data1 field changedInput schema / properties / tool / descriptionPrevious value: -"The tool whose result the app draws, from the text's _meta.tool"New value: +"The tool whose result the app draws, from the result's _meta.tool"v1.6.13tomtom-area-searchtomtom-data-viztomtom-dynamic-map19 fields changedInput schema / properties / center / descriptionPrevious value: -"Map center coordinates. Optional if bbox provided or if markers/routes are used for auto-calculation. IMPORTANT: If using 'center', also provide 'zoom' for best results. Use either center+zoom OR bbox, not both simultaneously. EXAMPLE: {lat: 52.3676, lon: 4.9041} for Amsterdam Central."New value: +"Map center coordinates. With 'zoom' it sets the view exactly; alone, the map centers here and zooms to fit the content. Ignored when 'bbox' is given. EXAMPLE: {lat: 52.3676, lon: 4.9041} for Amsterdam Central."Input schema / properties / center / properties / labelRemoved value: -{
- "description": "Optional custom label for the map center. This label will only appear if the center point is also added to markers. EXAMPLE: 'Map Center'.",
- "type": "string"
-}Input schema / properties / detailRemoved value: -{
- "default": "compact",
- "description": "Controls the image quality included in the tool response. 'compact' (DEFAULT): Compresses the image to stay under 1MB, using JPEG conversion and/or downscaling as needed. Best for most use cases since the interactive MCP app widget renders the full map separately. 'full': Returns the original full-resolution PNG image. Use when you need maximum image quality in the conversation, but note this may exceed the 1MB response limit for large/detailed maps.",
- "enum": [
- "compact",
- "full"
- ],
- "type": "string"
-}Input schema / properties / height / descriptionPrevious value: -"Map height in pixels (100-2048). Auto-calculated based on content if not provided. Recommended values: 600 (standard), 900 (detailed). EXAMPLE: 600 for standard display, 900 for detailed map."New value: +"Map viewport height in pixels (100-2048), used to fit the initial framing. DEFAULT: 400. EXAMPLE: 600 for standard display, 900 for a taller view."Input schema / properties / routeInfoDetailRemoved value: -{
- "description": "Level of route information to display when using routePlans. OPTIONS: 'basic' (simple), 'compact' (short), 'detailed' (full), 'distance-time' (time/distance only). DEFAULT: 'basic'. EXAMPLE: 'distance-time' to show just the travel distance and time.",
- "enum": [
- "basic",
- "compact",
- "detailed",
- "distance-time"
- ],
- "type": "string"
-}Input schema / properties / routePlans / descriptionPrevious value: -"Array of route calculations to draw on the map. Each entry is an independent origin→destination trip calculated via TomTom Routing API. NOTE: For standalone route queries (directions, travel time, distance), prefer the tomtom-routing tool instead. Use routePlans here only when you need to visualize calculated routes alongside other map elements (markers, polygons) in a single map image. Each plan can have its own routeType, travelMode, and color. EXAMPLE: [{origin: {lat: 52.37, lon: 4.89}, destination: {lat: 52.36, lon: 4.89}, label: 'Morning Commute'}, {origin: {lat: 48.86, lon: 2.35}, destination: {lat: 48.85, lon: 2.29}, label: 'Paris Tour'}]."New value: +"Array of route calculations to draw on the map. Each entry is an independent origin→destination trip calculated via TomTom Routing API. NOTE: For standalone route queries (directions, travel time, distance), prefer the tomtom-routing tool instead. Use routePlans here only when you need to visualize calculated routes alongside other map elements (markers, polygons) in a single map. Each plan can have its own routeType, travelMode, and color. EXAMPLE: [{origin: {lat: 52.37, lon: 4.89}, destination: {lat: 52.36, lon: 4.89}, label: 'Morning Commute'}, {origin: {lat: 48.86, lon: 2.35}, destination: {lat: 48.85, lon: 2.29}, label: 'Paris Tour'}]."Input schema / properties / routePlans / items / properties / avoid / items / enumAdded value: +[
+ "tollRoads",
+ "motorways",
+ "ferries",
+ "unpavedRoads",
+ "carpools",
+ "alreadyUsedRoads",
+ "borderCrossings",
+ "tunnels",
+ "carTrains",
+ "lowEmissionZones"
+]Input schema / properties / routePlans / items / properties / destination / properties / lat / descriptionPrevious value: -"Latitude coordinate (-90 to +90). Use precise coordinates from geocoding for best results. EXAMPLE: 52.36 for Rijksmuseum."New value: +"Latitude coordinate (-90 to +90). Use precise coordinates from geocoding for best results. EXAMPLE: 52.3676 for Amsterdam Central Station."Input schema / properties / routePlans / items / properties / destination / properties / lon / descriptionPrevious value: -"Longitude coordinate (-180 to +180). Use precise coordinates from geocoding for best results. EXAMPLE: 4.8852 for Rijksmuseum."New value: +"Longitude coordinate (-180 to +180). Use precise coordinates from geocoding for best results. EXAMPLE: 4.9041 for Amsterdam Central Station."Input schema / properties / routePlans / items / properties / routeType / descriptionPrevious value: -"Route calculation strategy. DEFAULT: 'fastest'. EXAMPLE: 'shortest' for minimum distance."New value: +"Route calculation strategy: 'fast' (time-optimized), 'short' (distance-optimized), 'efficient' (fuel-efficient), 'thrilling' (scenic). DEFAULT: 'fast'."Input schema / properties / routePlans / items / properties / routeType / enumPrevious value: -[
- "fastest",
- "shortest",
- "eco",
- "thrilling"
-]New value: +[
+ "fast",
+ "short",
+ "efficient",
+ "thrilling"
+]Input schema / properties / routePlans / items / properties / travelMode / descriptionPrevious value: -"Mode of transport. DEFAULT: 'car'. EXAMPLE: 'pedestrian' for walking routes."New value: +"Mode of transport. DEFAULT: 'car'. Only 'car' is supported."Input schema / properties / routePlans / items / properties / travelMode / enumPrevious value: -[
- "car",
- "truck",
- "bicycle",
- "pedestrian"
-]New value: +[
+ "car"
+]Input schema / properties / routes / items / properties / color / descriptionPrevious value: -"Route color in hex format (e.g., '#0066cc'). DEFAULT: system-defined color based on traffic conditions. EXAMPLE: '#FF0000' for red route, '#00FF00' for green route."New value: +"Route color in hex format (e.g., '#0066cc'). DEFAULT: '#007cbf'. EXAMPLE: '#FF0000' for red route, '#00FF00' for green route."Input schema / properties / routes / items / properties / points / items / properties / label / descriptionPrevious value: -"Optional custom label for this location. If not provided, defaults will be used (e.g., 'Start', 'End', 'Waypoint 1'). EXAMPLE: 'Amsterdam Central' or 'First Stop'."New value: +"Optional custom label for this location. If not provided, defaults will be used (e.g., 'Start', 'End', 'Waypoint 1'). EXAMPLE: 'Amsterdam Central' or 'Coffee Stop'."Input schema / properties / show_ui / defaultPrevious value: -falseNew value: +trueInput schema / properties / show_ui / descriptionPrevious value: -"Enable interactive MCP app visualization. When true, the response includes a viz_id that allows an MCP App to render an interactive version of the map with zoom, pan, and click capabilities. Set to false if you only need the static PNG image. DEFAULT: false."New value: +"Render the map in the interactive MCP app (zoom, pan, click). The map is drawn by the app, so leaving this on is what makes the tool produce anything visual. Set to false only when the caller just wants the request acknowledged without a map. DEFAULT: true."Input schema / properties / width / descriptionPrevious value: -"Map width in pixels (100-2048). Auto-calculated based on content if not provided. Recommended values: 800 (standard), 1200 (detailed). EXAMPLE: 800 for standard display, 1200 for detailed map."New value: +"Map viewport width in pixels (100-2048), used to fit the initial framing. DEFAULT: 600. EXAMPLE: 800 for standard display, 1200 for a wider view."Input schema / properties / zoom / descriptionPrevious value: -"Zoom level (0-22). EXAMPLES: 3 (continent), 6 (country), 10 (city), 15 (neighborhood), 18 (street), 20-22 (building detail). Auto-calculated if not provided. NOTE: Zoom levels 20+ are only useful for very small geographic areas."New value: +"Zoom level (0-22). EXAMPLES: 3 (continent), 6 (country), 10 (city), 15 (neighborhood), 18 (street), 20-22 (building detail). Without it the zoom fits the content (or the bbox). NOTE: Zoom levels 20+ are only useful for very small geographic areas."tomtom-ev-searchtomtom-fuzzy-search30 fields changedInput schema / properties / addressRangesRemoved value: -{
- "description": "Include address ranges in the response",
- "type": "boolean"
-}Input schema / properties / boundingBoxAdded value: +{
+ "description": "Bounding box as [minLon, minLat, maxLon, maxLat] (GeoJSON convention). Example: [4.8, 52.3, 4.95, 52.45] for Amsterdam area. Not with position.",
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 4,
+ "minItems": 4,
+ "type": "array"
+}Input schema / properties / brandSet / descriptionPrevious value: -"Filter by brand names. Examples: 'Starbucks,Peet\\'s', 'Marriott,Hilton'. Use quotes for brands with commas."New value: +"Filter by brand names, comma-separated. Examples: 'Starbucks', 'Marriott,Hilton'."Input schema / properties / btmRightRemoved value: -{
- "description": "Bottom-right coordinates of bounding box (format: 'lat,lon'). Must be used with topLeft",
- "type": "string"
-}Input schema / properties / categorySetRemoved value: -{
- "description": "Filter POI per category using category IDs.\n Examples: \n '7315' (Restaurant), '9361' (Shop), '7311' (Gas Station), '7321' (Hospital),\n '7397' (ATM), '7327' (Department Store), '7314' (Hotel/Motel), '9361009' (Convenience Store),\n '7324' (Post Office), '7383' (Airport), '7380' (Railroad Station), '9942' (Public Transportation Stop),\n '7313' (Parking Garage), '7369' (Open Parking Area), '7342' (Movie Theater),\n '9362' (Park & Recreation Area), '7310' (Repair Shop), '9376' (Café/Pub), '9379' (Nightlife),\n '7318' (Theater), '7317' (Museum), '7312' (Rent-a-Car Facility), '7372' (School),\n '7322' (Police Station), '7326' (Pharmacy), '9352' (Company), '7376' (Tourist Attraction),\n '7332005' (Supermarkets & Hypermarkets), '7315015' (Fast Food)",
- "type": "string"
-}Input schema / properties / connectorSet / descriptionPrevious value: -"EV connector types: 'IEC62196Type2CableAttached', 'Chademo', 'TeslaConnector'"New value: +"EV connector types, comma-separated. Examples: 'IEC62196Type2CCS', 'IEC62196Type2CableAttached,Chademo', 'Tesla'."Input schema / properties / countriesAdded value: +{
+ "description": "Limit results to specific countries using ISO alpha-2 codes. Example: ['US'], ['FR', 'GB'], ['NL', 'DE']",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / countrySetRemoved value: -{
- "description": "Limit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US'",
- "type": "string"
-}Input schema / properties / cursorAdded value: +{
+ "description": "The next page of results: the nextCursor of the previous response, with the same other parameters.",
+ "type": "string"
+}Input schema / properties / entityTypeSet / descriptionPrevious value: -"Filter results by geographic entity types. Valid values: PostalCodeArea,\n CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision,\n MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality.\n Note: This parameter is for geographic entities only, not POIs.\n For POI filtering, use categorySet instead"New value: +"Filter results by geographic entity types, comma-separated: Country, CountrySubdivision, CountrySecondarySubdivision, CountryTertiarySubdivision, Municipality, MunicipalitySubdivision, MunicipalitySecondarySubdivision, Neighbourhood, PostalCodeArea. Note: This parameter is for geographic entities only, not POIs. For POI filtering, use poiCategories instead"Input schema / properties / extRemoved value: -{
- "description": "Extended parameters for the search",
- "type": "string"
-}Input schema / properties / extendedPostalCodesFor / descriptionPrevious value: -"Include extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI'"New value: +"Comma-separated index types whose results carry extended postal codes: Geo, PAD, Addr, Str, XStr, and POI for POI results. Default: every type except Geo, so listing types removes the codes from the others. Examples: 'PAD,Addr', 'Geo'."Input schema / properties / fuelSet / descriptionPrevious value: -"Fuel types: 'Petrol', 'Diesel', 'LPG', 'Hydrogen', 'E85'"New value: +"Fuel types, comma-separated: Petrol, LPG, Diesel, Biodiesel, DieselForCommercialVehicles, E85, LNG, CNG, Hydrogen, AdBlue."Input schema / properties / geometriesRemoved value: -{
- "description": "Include geometries information in the response",
- "type": "boolean"
-}Input schema / properties / idxSet / descriptionPrevious value: -"Filter results by index set"New value: +"Search only these indexes, comma-separated: 'Geo' (geographies), 'PAD' (point addresses), 'Addr' (address ranges), 'Str' (streets), 'XStr' (cross streets), 'POI'."Input schema / properties / latRemoved value: -{
- "description": "Center latitude for location bias",
- "type": "number"
-}Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (1-100). Default: 5"New value: +"Maximum number of results to return (1-100). Default: 10."Input schema / properties / lonRemoved value: -{
- "description": "Center longitude for location bias",
- "type": "number"
-}Input schema / properties / mapcodes / descriptionPrevious value: -"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)."New value: +"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)."Input schema / properties / ofsRemoved value: -{
- "description": "Offset for pagination of results",
- "type": "number"
-}Input schema / properties / poiCategoriesAdded value: +{
+ "description": "Filter POI results by UPPER_SNAKE_CASE text category codes (e.g. 'RESTAURANT', 'PARKING_GARAGE'), NOT numeric IDs. IMPORTANT: Never guess codes — always call tomtom-poi-categories first with the user's intent as keywords to discover valid codes.",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 10,
+ "type": "array"
+}Input schema / properties / positionAdded value: +{
+ "description": "Center position as [longitude, latitude] for location bias (GeoJSON convention). Example: [4.89707, 52.377956] for Amsterdam. Not with boundingBox.",
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+}Input schema / properties / radius / descriptionPrevious value: -"Search radius in meters when lat/lon provided. Examples: 1000 (neighborhood), 5000 (city area), 20000 (metro area)."New value: +"Search radius in meters around position; needs position. Examples: 1000 (neighborhood), 5000 (city area), 20000 (metro area)."Input schema / properties / relatedPois / descriptionPrevious value: -"Include related points of interest"New value: +"Include related points of interest: 'off', 'child', 'parent' or 'all'. Default: 'off'."Input schema / properties / response_detail / descriptionPrevious value: -"Response detail level. 'compact' (default): trimmed response with essential fields only, saves tokens. 'full': complete API response with all fields including coordinates, classifications, etc."New value: +"Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger."Input schema / properties / show_uiAdded value: +{
+ "default": false,
+ "description": "Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false",
+ "type": "boolean"
+}Input schema / properties / topLeftRemoved value: -{
- "description": "Top-left coordinates of bounding box (format: 'lat,lon'). Must be used with btmRight",
- "type": "string"
-}Input schema / properties / vehicleTypeSetRemoved value: -{
- "description": "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",
- "type": "string"
-}Input schema / properties / view / descriptionPrevious value: -"Geopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN'"New value: +"Geopolitical view for disputed territories."Input schema / properties / view / enumAdded value: +[
+ "Unified",
+ "AE",
+ "AR",
+ "BN",
+ "CL",
+ "CN",
+ "DZ",
+ "IL",
+ "IN",
+ "KR",
+ "MA",
+ "MY",
+ "PH",
+ "PK",
+ "RS",
+ "RU",
+ "TR",
+ "TW",
+ "US",
+ "VN"
+]tomtom-geocode21 fields changedInput schema / properties / addressRangesRemoved value: -{
- "description": "Include address ranges in the response",
- "type": "boolean"
-}Input schema / properties / boundingBoxAdded value: +{
+ "description": "Bounding box as [minLon, minLat, maxLon, maxLat] (GeoJSON convention). Example: [4.8, 52.3, 4.95, 52.45] for Amsterdam area. Not with position.",
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 4,
+ "minItems": 4,
+ "type": "array"
+}Input schema / properties / btmRightRemoved value: -{
- "description": "Bottom-right coordinates of bounding box (format: 'lat,lon'). Must be used with topLeft",
- "type": "string"
-}Input schema / properties / countriesAdded value: +{
+ "description": "Limit results to specific countries using ISO alpha-2 codes. Example: ['US'], ['FR', 'GB'], ['NL', 'DE']",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / countrySetRemoved value: -{
- "description": "Limit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US'",
- "type": "string"
-}Input schema / properties / cursorAdded value: +{
+ "description": "The next page of results: the nextCursor of the previous response, with the same other parameters.",
+ "type": "string"
+}Input schema / properties / entityTypeSet / descriptionPrevious value: -"Filter results by geographic entity types. Valid values: PostalCodeArea,\n CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision,\n MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality.\n Note: This parameter is for geographic entities only, not POIs.\n For POI filtering, use categorySet instead"New value: +"Filter results by geographic entity types, comma-separated: Country, CountrySubdivision, CountrySecondarySubdivision, CountryTertiarySubdivision, Municipality, MunicipalitySubdivision, MunicipalitySecondarySubdivision, Neighbourhood, PostalCodeArea. Note: This parameter is for geographic entities only, not POIs. For POI filtering, use poiCategories instead"Input schema / properties / extendedPostalCodesFor / descriptionPrevious value: -"Include extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI'"New value: +"Comma-separated index types whose results carry extended postal codes: Geo, PAD, Addr, Str, XStr, and POI for POI results. Default: every type except Geo, so listing types removes the codes from the others. Examples: 'PAD,Addr', 'Geo'."Input schema / properties / geometriesRemoved value: -{
- "description": "Include geometries information in the response",
- "type": "boolean"
-}Input schema / properties / latRemoved value: -{
- "description": "Center latitude for location bias",
- "type": "number"
-}Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (1-100). Default: 5"New value: +"Maximum number of results to return (1-100). Default: 10."Input schema / properties / lonRemoved value: -{
- "description": "Center longitude for location bias",
- "type": "number"
-}Input schema / properties / mapcodes / descriptionPrevious value: -"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)."New value: +"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)."Input schema / properties / positionAdded value: +{
+ "description": "Center position as [longitude, latitude] for location bias (GeoJSON convention). Example: [4.89707, 52.377956] for Amsterdam. Not with boundingBox.",
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+}Input schema / properties / radius / descriptionPrevious value: -"Search radius in meters when lat/lon provided"New value: +"Search radius in meters around position; needs position."Input schema / properties / response_detail / descriptionPrevious value: -"Response detail level. 'compact' (default): trimmed response with essential fields only, saves tokens. 'full': complete API response with all fields including coordinates, classifications, etc."New value: +"Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger."Input schema / properties / show_uiAdded value: +{
+ "default": false,
+ "description": "Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false",
+ "type": "boolean"
+}Input schema / properties / timeZoneRemoved value: -{
- "description": "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",
- "type": "string"
-}Input schema / properties / topLeftRemoved value: -{
- "description": "Top-left coordinates of bounding box (format: 'lat,lon'). Must be used with btmRight",
- "type": "string"
-}Input schema / properties / view / descriptionPrevious value: -"Geopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN'"New value: +"Geopolitical view for disputed territories."Input schema / properties / view / enumAdded value: +[
+ "Unified",
+ "AE",
+ "AR",
+ "BN",
+ "CL",
+ "CN",
+ "DZ",
+ "IL",
+ "IN",
+ "KR",
+ "MA",
+ "MY",
+ "PH",
+ "PK",
+ "RS",
+ "RU",
+ "TR",
+ "TW",
+ "US",
+ "VN"
+]tomtom-get-app-datatomtom-get-viz-datatomtom-nearby32 fields changedInput schema / properties / addressRangesRemoved value: -{
- "description": "Include address ranges in the response",
- "type": "boolean"
-}Input schema / properties / brandSet / descriptionPrevious value: -"Filter by brand names. Examples: 'Starbucks,Peet\\'s', 'Marriott,Hilton'. Use quotes for brands with commas."New value: +"Filter by brand names, comma-separated. Examples: 'Starbucks', 'Marriott,Hilton'."Input schema / properties / categorySetRemoved value: -{
- "description": "Filter POI per category using category IDs.\n Examples: \n '7315' (Restaurant), '9361' (Shop), '7311' (Gas Station), '7321' (Hospital),\n '7397' (ATM), '7327' (Department Store), '7314' (Hotel/Motel), '9361009' (Convenience Store),\n '7324' (Post Office), '7383' (Airport), '7380' (Railroad Station), '9942' (Public Transportation Stop),\n '7313' (Parking Garage), '7369' (Open Parking Area), '7342' (Movie Theater),\n '9362' (Park & Recreation Area), '7310' (Repair Shop), '9376' (Café/Pub), '9379' (Nightlife),\n '7318' (Theater), '7317' (Museum), '7312' (Rent-a-Car Facility), '7372' (School),\n '7322' (Police Station), '7326' (Pharmacy), '9352' (Company), '7376' (Tourist Attraction),\n '7332005' (Supermarkets & Hypermarkets), '7315015' (Fast Food)",
- "type": "string"
-}Input schema / properties / chargingAvailabilityRemoved value: -{
- "description": "Include charging availability information for EV stations",
- "type": "boolean"
-}Input schema / properties / connectorSet / descriptionPrevious value: -"EV connector types: 'IEC62196Type2CableAttached', 'Chademo', 'TeslaConnector'"New value: +"EV connector types, comma-separated. Examples: 'IEC62196Type2CCS', 'IEC62196Type2CableAttached,Chademo', 'Tesla'."Input schema / properties / countriesAdded value: +{
+ "description": "Limit results to specific countries using ISO alpha-2 codes. Example: ['US'], ['FR', 'GB'], ['NL', 'DE']",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / countrySetRemoved value: -{
- "description": "Limit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US'",
- "type": "string"
-}Input schema / properties / cursorAdded value: +{
+ "description": "The next page of results: the nextCursor of the previous response, with the same other parameters.",
+ "type": "string"
+}Input schema / properties / entityTypeSetRemoved value: -{
- "description": "Filter results by geographic entity types. Valid values: PostalCodeArea,\n CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision,\n MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality.\n Note: This parameter is for geographic entities only, not POIs.\n For POI filtering, use categorySet instead",
- "type": "string"
-}Input schema / properties / extRemoved value: -{
- "description": "Extended parameters for the search",
- "type": "string"
-}Input schema / properties / extendedPostalCodesFor / descriptionPrevious value: -"Include extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI'"New value: +"Comma-separated index types whose results carry extended postal codes: Geo, PAD, Addr, Str, XStr, and POI for POI results. Default: every type except Geo, so listing types removes the codes from the others. Examples: 'PAD,Addr', 'Geo'."Input schema / properties / fuelAvailabilityRemoved value: -{
- "description": "Include fuel availability information for gas stations",
- "type": "boolean"
-}Input schema / properties / fuelSet / descriptionPrevious value: -"Fuel types: 'Petrol', 'Diesel', 'LPG', 'Hydrogen', 'E85'"New value: +"Fuel types, comma-separated: Petrol, LPG, Diesel, Biodiesel, DieselForCommercialVehicles, E85, LNG, CNG, Hydrogen, AdBlue."Input schema / properties / geometriesRemoved value: -{
- "description": "Include geometries information in the response",
- "type": "boolean"
-}Input schema / properties / latRemoved value: -{
- "description": "Center latitude for nearby search. Use precise coordinates from geocoding.",
- "type": "number"
-}Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (1-100). Default: 5"New value: +"Maximum number of results to return (1-100). Default: 20."Input schema / properties / lonRemoved value: -{
- "description": "Center longitude for nearby search. Use precise coordinates from geocoding.",
- "type": "number"
-}Input schema / properties / mapcodes / descriptionPrevious value: -"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)."New value: +"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)."Input schema / properties / maxFuzzyLevelRemoved value: -{
- "description": "Maximum fuzzy matching level (1-4)",
- "type": "number"
-}Input schema / properties / minFuzzyLevelRemoved value: -{
- "description": "Minimum fuzzy matching level (1-4)",
- "type": "number"
-}Input schema / properties / ofsRemoved value: -{
- "description": "Offset for pagination of results",
- "type": "number"
-}Input schema / properties / parkingAvailabilityRemoved value: -{
- "description": "Include parking availability information",
- "type": "boolean"
-}Input schema / properties / poiCategoriesAdded value: +{
+ "description": "POI categories to find, as UPPER_SNAKE_CASE codes (e.g. 'RESTAURANT', 'PARKING_GARAGE'), NOT numeric IDs. Required unless brandSet, connectorSet, fuelSet, minPowerKW or maxPowerKW is given. IMPORTANT: Never guess codes — always call tomtom-poi-categories first with the user's intent as keywords to discover valid codes.",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 10,
+ "type": "array"
+}Input schema / properties / positionAdded value: +{
+ "description": "Center position as [longitude, latitude] for nearby search (GeoJSON convention). Example: [4.89707, 52.377956] for Amsterdam. Use precise coordinates from geocoding.",
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+}Input schema / properties / relatedPois / descriptionPrevious value: -"Include related points of interest"New value: +"Include related points of interest: 'off', 'child', 'parent' or 'all'. Default: 'off'."Input schema / properties / response_detail / descriptionPrevious value: -"Response detail level. 'compact' (default): trimmed response with essential fields only, saves tokens. 'full': complete API response with all fields including coordinates, classifications, etc."New value: +"Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger."Input schema / properties / roadUseRemoved value: -{
- "description": "Include road usage information",
- "type": "boolean"
-}Input schema / properties / show_uiAdded value: +{
+ "default": false,
+ "description": "Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false",
+ "type": "boolean"
+}Input schema / properties / vehicleTypeSetRemoved value: -{
- "description": "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",
- "type": "string"
-}Input schema / properties / view / descriptionPrevious value: -"Geopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN'"New value: +"Geopolitical view for disputed territories."Input schema / properties / view / enumAdded value: +[
+ "Unified",
+ "AE",
+ "AR",
+ "BN",
+ "CL",
+ "CN",
+ "DZ",
+ "IL",
+ "IN",
+ "KR",
+ "MA",
+ "MY",
+ "PH",
+ "PK",
+ "RS",
+ "RU",
+ "TR",
+ "TW",
+ "US",
+ "VN"
+]Input schema / requiredPrevious value: -[
- "lat",
- "lon"
-]New value: +[
+ "position"
+]tomtom-poi-categoriestomtom-poi-search34 fields changedInput schema / properties / addressRangesRemoved value: -{
- "description": "Include address ranges in the response",
- "type": "boolean"
-}Input schema / properties / boundingBoxAdded value: +{
+ "description": "Bounding box as [minLon, minLat, maxLon, maxLat] (GeoJSON convention). Example: [4.8, 52.3, 4.95, 52.45] for Amsterdam area. Not with position.",
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 4,
+ "minItems": 4,
+ "type": "array"
+}Input schema / properties / brandSet / descriptionPrevious value: -"Filter by brand names. Examples: 'Starbucks,Peet\\'s', 'Marriott,Hilton'. Use quotes for brands with commas."New value: +"Filter by brand names, comma-separated. Examples: 'Starbucks', 'Marriott,Hilton'."Input schema / properties / btmRightRemoved value: -{
- "description": "Bottom-right coordinates of bounding box (format: 'lat,lon'). Must be used with topLeft",
- "type": "string"
-}Input schema / properties / categorySetRemoved value: -{
- "description": "Filter POI per category using category IDs.\n Examples: \n '7315' (Restaurant), '9361' (Shop), '7311' (Gas Station), '7321' (Hospital),\n '7397' (ATM), '7327' (Department Store), '7314' (Hotel/Motel), '9361009' (Convenience Store),\n '7324' (Post Office), '7383' (Airport), '7380' (Railroad Station), '9942' (Public Transportation Stop),\n '7313' (Parking Garage), '7369' (Open Parking Area), '7342' (Movie Theater),\n '9362' (Park & Recreation Area), '7310' (Repair Shop), '9376' (Café/Pub), '9379' (Nightlife),\n '7318' (Theater), '7317' (Museum), '7312' (Rent-a-Car Facility), '7372' (School),\n '7322' (Police Station), '7326' (Pharmacy), '9352' (Company), '7376' (Tourist Attraction),\n '7332005' (Supermarkets & Hypermarkets), '7315015' (Fast Food)",
- "type": "string"
-}Input schema / properties / chargingAvailabilityRemoved value: -{
- "description": "Include charging availability information for EV stations",
- "type": "boolean"
-}Input schema / properties / connectorSet / descriptionPrevious value: -"EV connector types: 'IEC62196Type2CableAttached', 'Chademo', 'TeslaConnector'"New value: +"EV connector types, comma-separated. Examples: 'IEC62196Type2CCS', 'IEC62196Type2CableAttached,Chademo', 'Tesla'."Input schema / properties / countriesAdded value: +{
+ "description": "Limit results to specific countries using ISO alpha-2 codes. Example: ['US'], ['FR', 'GB'], ['NL', 'DE']",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / countrySetRemoved value: -{
- "description": "Limit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US'",
- "type": "string"
-}Input schema / properties / cursorAdded value: +{
+ "description": "The next page of results: the nextCursor of the previous response, with the same other parameters.",
+ "type": "string"
+}Input schema / properties / entityTypeSetRemoved value: -{
- "description": "Filter results by geographic entity types. Valid values: PostalCodeArea,\n CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision,\n MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality.\n Note: This parameter is for geographic entities only, not POIs.\n For POI filtering, use categorySet instead",
- "type": "string"
-}Input schema / properties / extRemoved value: -{
- "description": "Extended parameters for the search",
- "type": "string"
-}Input schema / properties / extendedPostalCodesFor / descriptionPrevious value: -"Include extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI'"New value: +"Comma-separated index types whose results carry extended postal codes: Geo, PAD, Addr, Str, XStr, and POI for POI results. Default: every type except Geo, so listing types removes the codes from the others. Examples: 'PAD,Addr', 'Geo'."Input schema / properties / fuelAvailabilityRemoved value: -{
- "description": "Include fuel availability information for gas stations",
- "type": "boolean"
-}Input schema / properties / fuelSet / descriptionPrevious value: -"Fuel types: 'Petrol', 'Diesel', 'LPG', 'Hydrogen', 'E85'"New value: +"Fuel types, comma-separated: Petrol, LPG, Diesel, Biodiesel, DieselForCommercialVehicles, E85, LNG, CNG, Hydrogen, AdBlue."Input schema / properties / geometriesRemoved value: -{
- "description": "Include geometries information in the response",
- "type": "boolean"
-}Input schema / properties / latRemoved value: -{
- "description": "Latitude for location context. STRONGLY recommended for relevant local results.",
- "type": "number"
-}Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (1-100). Default: 5"New value: +"Maximum number of results to return (1-100). Default: 10."Input schema / properties / lonRemoved value: -{
- "description": "Longitude for location context. Must be used with lat parameter.",
- "type": "number"
-}Input schema / properties / mapcodes / descriptionPrevious value: -"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)."New value: +"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)."Input schema / properties / maxFuzzyLevelRemoved value: -{
- "description": "Maximum fuzzy matching level (1-4)",
- "type": "number"
-}Input schema / properties / minFuzzyLevelRemoved value: -{
- "description": "Minimum fuzzy matching level (1-4)",
- "type": "number"
-}Input schema / properties / ofsRemoved value: -{
- "description": "Offset for pagination of results",
- "type": "number"
-}Input schema / properties / parkingAvailabilityRemoved value: -{
- "description": "Include parking availability information",
- "type": "boolean"
-}Input schema / properties / poiCategoriesAdded value: +{
+ "description": "Filter POI results by UPPER_SNAKE_CASE text category codes (e.g. 'RESTAURANT', 'PARKING_GARAGE'), NOT numeric IDs. IMPORTANT: Never guess codes — always call tomtom-poi-categories first with the user's intent as keywords to discover valid codes.",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 10,
+ "type": "array"
+}Input schema / properties / positionAdded value: +{
+ "description": "Center position as [longitude, latitude] for location bias (GeoJSON convention). Example: [4.89707, 52.377956] for Amsterdam. Not with boundingBox.",
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+}Input schema / properties / radius / descriptionPrevious value: -"Search radius in meters. Essential for focused local results. Examples: 1000 (walking), 5000 (driving), 20000 (wide area)."New value: +"Search radius in meters around position; needs position. Examples: 1000 (walking), 5000 (driving), 20000 (wide area)."Input schema / properties / relatedPois / descriptionPrevious value: -"Include related points of interest"New value: +"Include related points of interest: 'off', 'child', 'parent' or 'all'. Default: 'off'."Input schema / properties / response_detail / descriptionPrevious value: -"Response detail level. 'compact' (default): trimmed response with essential fields only, saves tokens. 'full': complete API response with all fields including coordinates, classifications, etc."New value: +"Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger."Input schema / properties / show_uiAdded value: +{
+ "default": false,
+ "description": "Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false",
+ "type": "boolean"
+}Input schema / properties / topLeftRemoved value: -{
- "description": "Top-left coordinates of bounding box (format: 'lat,lon'). Must be used with btmRight",
- "type": "string"
-}Input schema / properties / vehicleTypeSetRemoved value: -{
- "description": "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",
- "type": "string"
-}Input schema / properties / view / descriptionPrevious value: -"Geopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN'"New value: +"Geopolitical view for disputed territories."Input schema / properties / view / enumAdded value: +[
+ "Unified",
+ "AE",
+ "AR",
+ "BN",
+ "CL",
+ "CN",
+ "DZ",
+ "IL",
+ "IN",
+ "KR",
+ "MA",
+ "MY",
+ "PH",
+ "PK",
+ "RS",
+ "RU",
+ "TR",
+ "TW",
+ "US",
+ "VN"
+]tomtom-reachable-rangetomtom-report-app-statustomtom-reverse-geocode27 fields changedInput schema / properties / addressRangesRemoved value: -{
- "description": "Include address ranges in the response",
- "type": "boolean"
-}Input schema / properties / allowFreeformNewLineRemoved value: -{
- "description": "Allow newlines in freeform addresses",
- "type": "boolean"
-}Input schema / properties / countrySetRemoved value: -{
- "description": "Limit results to specific countries using ISO codes. Examples: 'US', 'FR,GB', 'CA,US'",
- "type": "string"
-}Input schema / properties / entityTypeAdded value: +{
+ "description": "Filter by geography entity types, comma-separated: Country, CountrySubdivision, CountrySecondarySubdivision, CountryTertiarySubdivision, Municipality, MunicipalitySubdivision, MunicipalitySecondarySubdivision, Neighbourhood, PostalCodeArea. Not with heading, which the API then ignores.",
+ "type": "string"
+}Input schema / properties / entityTypeSetRemoved value: -{
- "description": "Filter results by geographic entity types. Valid values: PostalCodeArea,\n CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision,\n MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality.\n Note: This parameter is for geographic entities only, not POIs.\n For POI filtering, use categorySet instead",
- "type": "string"
-}Input schema / properties / extendedPostalCodesForRemoved value: -{
- "description": "Include extended postal codes for specific index types. Examples: 'PAD', 'PAD,Addr', 'POI'",
- "type": "string"
-}Input schema / properties / geometriesRemoved value: -{
- "description": "Include geometries information in the response",
- "type": "boolean"
-}Input schema / properties / latRemoved value: -{
- "description": "Latitude coordinate (-90 to +90). Precision to 4+ decimal places recommended.",
- "type": "number"
-}Input schema / properties / limitRemoved value: -{
- "description": "Maximum number of results to return (1-100). Default: 5",
- "maximum": 100,
- "minimum": 1,
- "type": "number"
-}Input schema / properties / lonRemoved value: -{
- "description": "Longitude coordinate (-180 to +180). Precision to 4+ decimal places recommended.",
- "type": "number"
-}Input schema / properties / mapcodesRemoved value: -{
- "description": "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).",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Input schema / properties / maxResultsRemoved value: -{
- "description": "Maximum results to return (alias for limit)",
- "type": "number"
-}Input schema / properties / ofsRemoved value: -{
- "description": "Offset for pagination of results",
- "type": "number"
-}Input schema / properties / positionAdded value: +{
+ "description": "Position as [longitude, latitude] to reverse geocode (GeoJSON convention). Precision to 4+ decimal places recommended. Example: [4.89707, 52.377956].",
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+}Input schema / properties / response_detail / descriptionPrevious value: -"Response detail level. 'compact' (default): trimmed response with essential fields only, saves tokens. 'full': complete API response with all fields including coordinates, classifications, etc."New value: +"Response detail level. 'compact' (default): essential fields and point coordinates, saves tokens. 'full': the raw API response with every field, lossless and much larger."Input schema / properties / returnAddressNamesRemoved value: -{
- "description": "Include address names in the response",
- "type": "boolean"
-}Input schema / properties / returnCommuneRemoved value: -{
- "description": "Include commune information in the results",
- "type": "boolean"
-}Input schema / properties / returnMatchTypeRemoved value: -{
- "description": "Include information about the type of geocoding match achieved",
- "type": "boolean"
-}Input schema / properties / returnRoadAccessibilityRemoved value: -{
- "description": "Include road accessibility information",
- "type": "boolean"
-}Input schema / properties / returnRoadUseRemoved value: -{
- "description": "Include road use types for street level results",
- "type": "boolean"
-}Input schema / properties / returnSpeedLimitRemoved value: -{
- "description": "Include posted speed limit for street results",
- "type": "boolean"
-}Input schema / properties / roadUseRemoved value: -{
- "description": "Types of road use to include in the results. Examples: 'Arterial', 'Ferry', 'Highway', etc.",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Input schema / properties / show_uiAdded value: +{
+ "default": false,
+ "description": "Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false",
+ "type": "boolean"
+}Input schema / properties / timeZoneRemoved value: -{
- "description": "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",
- "type": "string"
-}Input schema / properties / view / descriptionPrevious value: -"Geopolitical view for disputed territories. Options: 'Unified', 'AR', 'IL', 'IN', 'MA', 'PK', 'RU', 'TR', 'CN'"New value: +"Geopolitical view for disputed territories."Input schema / properties / view / enumAdded value: +[
+ "Unified",
+ "AE",
+ "AR",
+ "BN",
+ "CL",
+ "CN",
+ "DZ",
+ "IL",
+ "IN",
+ "KR",
+ "MA",
+ "MY",
+ "PH",
+ "PK",
+ "RS",
+ "RU",
+ "TR",
+ "TW",
+ "US",
+ "VN"
+]Input schema / requiredPrevious value: -[
- "lat",
- "lon"
-]New value: +[
+ "position"
+]tomtom-routing59 fields changedInput schema / properties / accelerationEfficiencyRemoved value: -{
- "description": "Efficiency during acceleration (0-1).",
- "type": "number"
-}Input schema / properties / alternativeTypeRemoved value: -{
- "description": "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`",
- "enum": [
- "anyRoute",
- "betterRoute"
- ],
- "type": "string"
-}Input schema / properties / auxiliaryPowerInLitersPerHourRemoved value: -{
- "description": "Auxiliary power consumption for combustion vehicles in L/hr.",
- "type": "number"
-}Input schema / properties / auxiliaryPowerInkWRemoved value: -{
- "description": "Auxiliary power consumption in kW for electric vehicles.",
- "type": "number"
-}Input schema / properties / avoid / descriptionPrevious value: -"Route features to avoid. May increase travel time. Options: 'tollRoads','motorways','ferries','unpavedRoads','carpools','alreadyUsedRoads'. Accepts array of string(s)."New value: +"Route features to avoid. May increase travel time."Input schema / properties / avoid / items / enumAdded value: +[
+ "tollRoads",
+ "motorways",
+ "ferries",
+ "unpavedRoads",
+ "carpools",
+ "alreadyUsedRoads",
+ "borderCrossings",
+ "tunnels",
+ "carTrains",
+ "lowEmissionZones"
+]Input schema / properties / chargeMarginsInkWhRemoved value: -{
- "description": "Comma-separated charge margins in kWh for route planning.",
- "type": "string"
-}Input schema / properties / computeBestOrderRemoved value: -{
- "description": "Reorder waypoints for optimization. Use with multiple waypoints to find the most efficient route order.",
- "type": "boolean"
-}Input schema / properties / computeTravelTimeForRemoved value: -{
- "description": "Calculate travel times for all segments ('all') or none ('none').",
- "enum": [
- "all",
- "none"
- ],
- "type": "string"
-}Input schema / properties / constantSpeedConsumptionInLitersPerHundredkmRemoved value: -{
- "description": "Combustion speed-to-consumption mappings: '50,6.3:130,11.5' (speed in km/h, consumption in L/100km).",
- "type": "string"
-}Input schema / properties / constantSpeedConsumptionInkWhPerHundredkmRemoved value: -{
- "description": "EV speed-to-consumption mappings format: '50,8.2:130,21.3' (speed in km/h, consumption in kWh/100km).",
- "type": "string"
-}Input schema / properties / consumptionInkWhPerkmAltitudeGainRemoved value: -{
- "description": "Energy used per km of altitude gain.",
- "type": "number"
-}Input schema / properties / currentChargeInkWhRemoved value: -{
- "description": "Current EV battery charge in kWh. Required for EV routing.",
- "type": "number"
-}Input schema / properties / currentFuelInLitersRemoved value: -{
- "description": "Current fuel level in liters for combustion vehicles.",
- "type": "number"
-}Input schema / properties / decelerationEfficiencyRemoved value: -{
- "description": "Efficiency during deceleration (0-1).",
- "type": "number"
-}Input schema / properties / destinationRemoved value: -{
- "description": "Destination coordinates. Obtain from geocoding for best results.",
- "properties": {
- "lat": {
- "description": "Latitude coordinate (-90 to +90). Use precise coordinates from geocoding for best results.",
- "type": "number"
- },
- "lon": {
- "description": "Longitude coordinate (-180 to +180). Use precise coordinates from geocoding for best results.",
- "type": "number"
- }
- },
- "required": [
- "lat",
- "lon"
- ],
- "type": "object"
-}Input schema / properties / downhillEfficiencyRemoved value: -{
- "description": "Efficiency during downhill driving (0-1).",
- "type": "number"
-}Input schema / properties / extendedRouteRepresentationRemoved value: -{
- "description": "Additional routing data formats to include in the response.",
- "type": "string"
-}Input schema / properties / fuelEnergyDensityInMJoulesPerLiterRemoved value: -{
- "description": "Fuel energy density in megajoules per liter.",
- "type": "number"
-}Input schema / properties / hillinessRemoved value: -{
- "description": "Preference for avoiding hills. Use 'low' for flatter routes.",
- "enum": [
- "low",
- "normal",
- "high"
- ],
- "type": "string"
-}Input schema / properties / includeTollPaymentTypesRemoved value: -{
- "description": "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",
- "type": "string"
-}Input schema / properties / instructionsTypeRemoved value: -{
- "description": "Instruction format: 'text' (human-readable), 'coded' (machine-readable), 'tagged' (HTML).",
- "enum": [
- "coded",
- "text",
- "tagged"
- ],
- "type": "string"
-}Input schema / properties / languageRemoved value: -{
- "description": "Language code for instructions (e.g., 'en-US', 'de-DE').",
- "type": "string"
-}Input schema / properties / locationsAdded value: +{
+ "description": "Ordered list of coordinates [origin, ...intermediateStops, destination]. Minimum 2 (origin + destination); add intermediate positions for multi-stop routes. Use geocoding for accurate coordinates.",
+ "items": {
+ "description": "Position as [longitude, latitude] (GeoJSON convention, lng first). Example: [4.89707, 52.377956] for Amsterdam, [13.404954, 52.520008] for Berlin.",
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+ },
+ "minItems": 2,
+ "type": "array"
+}Input schema / properties / maxChargeInkWhRemoved value: -{
- "description": "Maximum EV battery capacity in kWh. Required for EV routing.",
- "type": "number"
-}Input schema / properties / originRemoved value: -{
- "description": "Starting point coordinates. Obtain from geocoding for best results.",
- "properties": {
- "lat": {
- "description": "Latitude coordinate (-90 to +90). Use precise coordinates from geocoding for best results.",
- "type": "number"
- },
- "lon": {
- "description": "Longitude coordinate (-180 to +180). Use precise coordinates from geocoding for best results.",
- "type": "number"
- }
- },
- "required": [
- "lat",
- "lon"
- ],
- "type": "object"
-}Input schema / properties / recuperationInkWhPerkmAltitudeLossRemoved value: -{
- "description": "Energy recovered per km of altitude loss.",
- "type": "number"
-}Input schema / properties / reportRemoved value: -{
- "description": "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",
- "type": "string"
-}Input schema / properties / response_detail / descriptionPrevious value: -"Response detail level. 'compact' (default): trimmed response with essential fields only, saves tokens. 'full': complete API response with all fields including coordinates, classifications, etc."New value: +"Response detail level. 'compact' (default): essential fields and point coordinates, no geometry. 'geometry': compact plus a 'geometry' key holding a GeoJSON FeatureCollection ([lon, lat], at most 1,000 vertices per feature); use this to get coordinates to draw or process. 'full': the raw API response, lossless and many times larger."Input schema / properties / response_detail / enumPrevious value: -[
- "compact",
- "full"
-]New value: +[
+ "compact",
+ "geometry",
+ "full"
+]Input schema / properties / routeRepresentationRemoved value: -{
- "description": "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",
- "enum": [
- "polyline",
- "summaryOnly",
- "encodedPolyline",
- "none"
- ],
- "type": "string"
-}Input schema / properties / routeType / descriptionPrevious value: -"Route optimization: 'fastest' (time-optimized), 'shortest' (distance-optimized), 'eco' (fuel-efficient), 'thrilling' (scenic)."New value: +"Route optimization: 'fast' (time-optimized), 'short' (distance-optimized), 'efficient' (fuel-efficient), 'thrilling' (scenic). Default: 'fast'."Input schema / properties / routeType / enumPrevious value: -[
- "fastest",
- "shortest",
- "eco",
- "thrilling"
-]New value: +[
+ "fast",
+ "short",
+ "efficient",
+ "thrilling"
+]Input schema / properties / sectionType / descriptionPrevious value: -"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."New value: +"Keep only these section types in the route, besides leg. Default: all types the route has. Compact responses drop the map-rendering types (urban, tunnel, motorway, lowEmissionZone, pedestrian, speedLimit, roadShields, vehicleRestricted); they appear only with response_detail 'full'."Input schema / properties / sectionType / items / enumAdded value: +[
+ "carpool",
+ "carTrain",
+ "country",
+ "ferry",
+ "importantRoadStretch",
+ "lowEmissionZone",
+ "motorway",
+ "pedestrian",
+ "roadShields",
+ "speedLimit",
+ "toll",
+ "tollRoad",
+ "tollVignette",
+ "traffic",
+ "tunnel",
+ "unpaved",
+ "urban",
+ "vehicleRestricted"
+]Input schema / properties / show_uiAdded value: +{
+ "default": false,
+ "description": "Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false",
+ "type": "boolean"
+}Input schema / properties / supportingPointsRemoved value: -{
- "description": "Additional coordinates that influence the route shape without being stops (format: 'lat,lon;lat,lon').",
- "type": "string"
-}Input schema / properties / traffic / descriptionPrevious value: -"Include real-time traffic data for more accurate ETAs and route suggestions."New value: +"Traffic consideration: 'live' (real-time + historical), 'historical' (historical only)."Input schema / properties / traffic / enumAdded value: +[
+ "live",
+ "historical"
+]Input schema / properties / traffic / typePrevious value: -"boolean"New value: +"string"Input schema / properties / travelMode / enumPrevious value: -[
- "car",
- "pedestrian",
- "bicycle",
- "truck",
- "taxi",
- "bus",
- "van"
-]New value: +[
+ "car"
+]Input schema / properties / uphillEfficiencyRemoved value: -{
- "description": "Efficiency during uphill driving (0-1).",
- "type": "number"
-}Input schema / properties / vehicleAdrTunnelRestrictionCodeRemoved value: -{
- "description": "ADR tunnel restriction code for hazardous materials.",
- "type": "string"
-}Input schema / properties / vehicleAxleWeightRemoved value: -{
- "description": "Vehicle axle weight in kg for weight-restricted roads.",
- "type": "number"
-}Input schema / properties / vehicleCommercialRemoved value: -{
- "description": "Commercial vehicle flag. Affects road access restrictions.",
- "type": "boolean"
-}Input schema / properties / vehicleEngineTypeRemoved value: -{
- "description": "Engine type for fuel/energy consumption calculation.",
- "enum": [
- "combustion",
- "electric"
- ],
- "type": "string"
-}Input schema / properties / vehicleHeading / descriptionPrevious value: -"Heading of the vehicle in degrees (0-359) for more accurate initial routing."New value: +"Heading of the vehicle at the origin, in degrees clockwise from north (0-359), for a route that starts in the direction of travel."Input schema / properties / vehicleHeading / maximumAdded value: +359Input schema / properties / vehicleHeading / minimumAdded value: +0Input schema / properties / vehicleHeightRemoved value: -{
- "description": "Vehicle height in meters. Used to avoid low bridges.",
- "type": "number"
-}Input schema / properties / vehicleLengthRemoved value: -{
- "description": "Vehicle length in meters. Affects maneuverability restrictions.",
- "type": "number"
-}Input schema / properties / vehicleLoadTypeRemoved value: -{
- "description": "Cargo type for hazardous materials routing.",
- "type": "string"
-}Input schema / properties / vehicleMaxSpeed / exclusiveMinimumAdded value: +0Input schema / properties / vehicleNumberOfAxlesRemoved value: -{
- "description": "Number of axles on the vehicle. Used for toll calculations and restrictions.",
- "type": "number"
-}Input schema / properties / vehicleWeight / descriptionPrevious value: -"Vehicle weight in kg. Important for truck routing restrictions."New value: +"Vehicle weight in kg."Input schema / properties / vehicleWeight / exclusiveMinimumAdded value: +0Input schema / properties / vehicleWidthRemoved value: -{
- "description": "Vehicle width in meters. Used to avoid narrow roads.",
- "type": "number"
-}Input schema / properties / windingnessRemoved value: -{
- "description": "Preference for avoiding winding roads. Use 'low' for straighter routes.",
- "enum": [
- "low",
- "normal",
- "high"
- ],
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "origin",
- "destination"
-]New value: +[
+ "locations"
+]tomtom-search-along-routetomtom-static-maptomtom-traffic17 fields changedInput schema / properties / bbox / descriptionPrevious value: -"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."New value: +"Bounding box as [minLon, minLat, maxLon, maxLat] (GeoJSON convention). Example: [-74.02, 40.70, -73.96, 40.80] for lower Manhattan. Use smaller areas for better results."Input schema / properties / bbox / itemsAdded value: +{
+ "type": "number"
+}Input schema / properties / bbox / maxItemsAdded value: +4Input schema / properties / bbox / minItemsAdded value: +4Input schema / properties / bbox / typePrevious value: -"string"New value: +"array"Input schema / properties / categoryFilter / descriptionPrevious value: -"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)."New value: +"Incident categories to return. Default: all categories."Input schema / properties / categoryFilter / itemsAdded value: +{
+ "enum": [
+ "accident",
+ "broken-down-vehicle",
+ "danger",
+ "flooding",
+ "fog",
+ "frost",
+ "jam",
+ "lane-closed",
+ "other",
+ "rain",
+ "road-closed",
+ "roadworks",
+ "wind"
+ ],
+ "type": "string"
+}Input schema / properties / categoryFilter / typePrevious value: -"string"New value: +"array"Input schema / properties / maxResults / descriptionPrevious value: -"Maximum incidents to return (1-1000). Default: 100. Use 10-20 for readability in high-traffic areas. When more incidents match, the most severe are returned and the response includes an incidentSummary with full totals."New value: +"Maximum number of incidents to return (1-1000). Default: 100. When more incidents match, the most severe are returned and the response includes an incidentSummary with full totals."Input schema / properties / response_detail / descriptionPrevious value: -"Response detail level. 'compact' (default): trimmed response with essential fields only, saves tokens. 'full': complete API response with all fields including coordinates, classifications, etc."New value: +"Response detail level. 'compact' (default): essential fields and point coordinates, no geometry. 'geometry': compact plus a 'geometry' key holding a GeoJSON FeatureCollection ([lon, lat], at most 1,000 vertices per feature); use this to get coordinates to draw or process. 'full': the raw API response, lossless and many times larger."Input schema / properties / response_detail / enumPrevious value: -[
- "compact",
- "full"
-]New value: +[
+ "compact",
+ "geometry",
+ "full"
+]Input schema / properties / show_uiAdded value: +{
+ "default": false,
+ "description": "Request the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false",
+ "type": "boolean"
+}Input schema / properties / timeValidityFilter / descriptionPrevious value: -"Time validity filter: 'present' (current), 'future' (upcoming). Default: 'present'."New value: +"Which incidents to return by time: 'present' (happening now), 'future' (planned, e.g. road works). Default: ['present']."Input schema / properties / timeValidityFilter / enumRemoved value: -[
- "present",
- "future"
-]Input schema / properties / timeValidityFilter / itemsAdded value: +{
+ "enum": [
+ "present",
+ "future"
+ ],
+ "type": "string"
+}Input schema / properties / timeValidityFilter / typePrevious value: -"string"New value: +"array"Input schema / requiredAdded value: +[
+ "bbox"
+]tomtom-waypoint-routingv1.6.8tomtom-dynamic-maptomtom-fuzzy-search8 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / categorySet / descriptionPrevious value: -"Filter by POI categories. Common IDs: '7315' (restaurants), '7309' (gas), '7311' (hotels), '9663' (EV charging)."New value: +"Filter POI per category using category IDs.\n Examples: \n '7315' (Restaurant), '9361' (Shop), '7311' (Gas Station), '7321' (Hospital),\n '7397' (ATM), '7327' (Department Store), '7314' (Hotel/Motel), '9361009' (Convenience Store),\n '7324' (Post Office), '7383' (Airport), '7380' (Railroad Station), '9942' (Public Transportation Stop),\n '7313' (Parking Garage), '7369' (Open Parking Area), '7342' (Movie Theater),\n '9362' (Park & Recreation Area), '7310' (Repair Shop), '9376' (Café/Pub), '9379' (Nightlife),\n '7318' (Theater), '7317' (Museum), '7312' (Rent-a-Car Facility), '7372' (School),\n '7322' (Police Station), '7326' (Pharmacy), '9352' (Company), '7376' (Tourist Attraction),\n '7332005' (Supermarkets & Hypermarkets), '7315015' (Fast Food)"Input schema / properties / connectorsRemoved value: -{
- "description": "Include connector information for EV stations",
- "type": "boolean"
-}Input schema / properties / entityTypeSet / descriptionPrevious value: -"Filter results by entity types"New value: +"Filter results by geographic entity types. Valid values: PostalCodeArea,\n CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision,\n MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality.\n Note: This parameter is for geographic entities only, not POIs.\n For POI filtering, use categorySet instead"Input schema / properties / gomListRemoved value: -{
- "description": "Include geometry-only matches in the result list",
- "type": "boolean"
-}Input schema / properties / response_detailAdded 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"
+}Input schema / properties / roadUseRemoved value: -{
- "description": "Include road usage information",
- "type": "boolean"
-}Input schema / properties / sortRemoved value: -{
- "description": "Sort options for results",
- "type": "string"
-}tomtom-geocode3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / entityTypeSet / descriptionPrevious value: -"Filter results by geographic entity types. Valid values: PostalCodeArea, CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision, MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality. Note: This parameter is for geographic entities only, not POIs. For POI filtering, use categorySet instead"New value: +"Filter results by geographic entity types. Valid values: PostalCodeArea,\n CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision,\n MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality.\n Note: This parameter is for geographic entities only, not POIs.\n For POI filtering, use categorySet instead"Input schema / properties / response_detailAdded 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"
+}tomtom-get-api-keytomtom-get-app-configtomtom-get-viz-datatomtom-nearby5 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / categorySet / descriptionPrevious value: -"POI category filter. Common: '7315' (restaurants), '7309' (gas), '9663' (EV charging), '7311' (hotels), '9376' (parking)."New value: +"Filter POI per category using category IDs.\n Examples: \n '7315' (Restaurant), '9361' (Shop), '7311' (Gas Station), '7321' (Hospital),\n '7397' (ATM), '7327' (Department Store), '7314' (Hotel/Motel), '9361009' (Convenience Store),\n '7324' (Post Office), '7383' (Airport), '7380' (Railroad Station), '9942' (Public Transportation Stop),\n '7313' (Parking Garage), '7369' (Open Parking Area), '7342' (Movie Theater),\n '9362' (Park & Recreation Area), '7310' (Repair Shop), '9376' (Café/Pub), '9379' (Nightlife),\n '7318' (Theater), '7317' (Museum), '7312' (Rent-a-Car Facility), '7372' (School),\n '7322' (Police Station), '7326' (Pharmacy), '9352' (Company), '7376' (Tourist Attraction),\n '7332005' (Supermarkets & Hypermarkets), '7315015' (Fast Food)"Input schema / properties / entityTypeSet / descriptionPrevious value: -"Filter results by entity types"New value: +"Filter results by geographic entity types. Valid values: PostalCodeArea,\n CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision,\n MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality.\n Note: This parameter is for geographic entities only, not POIs.\n For POI filtering, use categorySet instead"Input schema / properties / response_detailAdded 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"
+}Input schema / properties / sortRemoved value: -{
- "description": "Sort options for results",
- "type": "string"
-}tomtom-poi-search7 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / categorySet / descriptionPrevious value: -"Filter by POI categories. Common IDs: '7315' (restaurants), '7309' (gas), '7311' (hotels), '9663' (EV charging)."New value: +"Filter POI per category using category IDs.\n Examples: \n '7315' (Restaurant), '9361' (Shop), '7311' (Gas Station), '7321' (Hospital),\n '7397' (ATM), '7327' (Department Store), '7314' (Hotel/Motel), '9361009' (Convenience Store),\n '7324' (Post Office), '7383' (Airport), '7380' (Railroad Station), '9942' (Public Transportation Stop),\n '7313' (Parking Garage), '7369' (Open Parking Area), '7342' (Movie Theater),\n '9362' (Park & Recreation Area), '7310' (Repair Shop), '9376' (Café/Pub), '9379' (Nightlife),\n '7318' (Theater), '7317' (Museum), '7312' (Rent-a-Car Facility), '7372' (School),\n '7322' (Police Station), '7326' (Pharmacy), '9352' (Company), '7376' (Tourist Attraction),\n '7332005' (Supermarkets & Hypermarkets), '7315015' (Fast Food)"Input schema / properties / entityTypeSet / descriptionPrevious value: -"Filter results by entity types"New value: +"Filter results by geographic entity types. Valid values: PostalCodeArea,\n CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision,\n MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality.\n Note: This parameter is for geographic entities only, not POIs.\n For POI filtering, use categorySet instead"Input schema / properties / query / descriptionPrevious value: -"Specific POI category search. Best for finding types of businesses: 'restaurants', 'gas stations', 'hotels', 'parking', 'ATMs', 'hospitals'"New value: +"Name of the POI to search for. If the intended query is a POI category like 'restaurant', provide an empty string for this param and use the category filter parameter to apply the desired category filter."Input schema / properties / response_detailAdded 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"
+}Input schema / properties / roadUseRemoved value: -{
- "description": "Include road usage information",
- "type": "boolean"
-}Input schema / properties / sortRemoved value: -{
- "description": "Sort options for results",
- "type": "string"
-}tomtom-reachable-range7 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / distanceBudgetInMeters / descriptionPrevious 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."Input schema / properties / energyBudgetInkWh / descriptionPrevious 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."Input schema / properties / fuelBudgetInLiters / descriptionPrevious 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."Input schema / properties / origin / additionalPropertiesRemoved value: -falseInput schema / properties / response_detailAdded 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"
+}Input schema / properties / timeBudgetInSec / descriptionPrevious 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."tomtom-reverse-geocode3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / entityTypeSet / descriptionPrevious value: -"Filter by entity types: 'Country', 'Municipality', etc."New value: +"Filter results by geographic entity types. Valid values: PostalCodeArea,\n CountryTertiarySubdivision, CountrySecondarySubdivision, MunicipalitySubdivision,\n MunicipalitySecondarySubdivision, Country, CountrySubdivision, Neighbourhood, Municipality.\n Note: This parameter is for geographic entities only, not POIs.\n For POI filtering, use categorySet instead"Input schema / properties / response_detailAdded 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"
+}tomtom-routing10 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / destination / additionalPropertiesRemoved value: -falseInput schema / properties / destination / properties / lat / $refRemoved value: -"#/properties/origin/properties/lat"Input schema / properties / destination / properties / lat / descriptionAdded value: +"Latitude coordinate (-90 to +90). Use precise coordinates from geocoding for best results."Input schema / properties / destination / properties / lat / typeAdded value: +"number"Input schema / properties / destination / properties / lon / $refRemoved value: -"#/properties/origin/properties/lon"Input schema / properties / destination / properties / lon / descriptionAdded value: +"Longitude coordinate (-180 to +180). Use precise coordinates from geocoding for best results."Input schema / properties / destination / properties / lon / typeAdded value: +"number"Input schema / properties / origin / additionalPropertiesRemoved value: -falseInput schema / properties / response_detailAdded 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"
+}tomtom-static-map2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / center / additionalPropertiesRemoved value: -falsetomtom-traffic8 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / incidentTypesRemoved value: -{
- "description": "Filter by incident types (comma-separated): '0' (Accident), '1' (Fog), '4' (Ice), '5' (Lane Restrictions), '7' (Closure), '8' (Roadworks).",
- "type": "string"
-}Input schema / properties / language / descriptionPrevious value: -"Language for incident descriptions: 'en-US', 'de-DE', 'fr-FR', 'es-ES'. Default: 'en-US'."New value: +"Language for incident descriptions: 'en-GB', 'de-DE', 'fr-FR', 'es-ES'. Default: 'en-GB'."Input schema / properties / maxResults / descriptionPrevious value: -"Maximum incidents to return (1-1000). Use 10-20 for readability in high-traffic areas."New value: +"Maximum incidents to return (1-1000). Default: 100. Use 10-20 for readability in high-traffic areas. When more incidents match, the most severe are returned and the response includes an incidentSummary with full totals."Input schema / properties / response_detailAdded 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"
+}Input schema / properties / tRemoved value: -{
- "description": "Unix Timestamp in seconds for traffic model. Use current time if not provided.",
- "type": "number"
-}Input schema / properties / timeFilterRemoved value: -{
- "description": "Time validity filter: 'present' (current), 'future' (upcoming), 'all' (both). Default: 'present'.",
- "enum": [
- "present",
- "future"
- ],
- "type": "string"
-}Input schema / properties / timeValidityFilterAdded value: +{
+ "description": "Time validity filter: 'present' (current), 'future' (upcoming). Default: 'present'.",
+ "enum": [
+ "present",
+ "future"
+ ],
+ "type": "string"
+}tomtom-waypoint-routing3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / response_detailAdded 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"
+}Input schema / properties / waypoints / items / additionalPropertiesRemoved value: -falsev1.0.0tomtom-fuzzy-searchtomtom-geocodetomtom-nearbytomtom-poi-searchtomtom-reachable-rangetomtom-reverse-geocodetomtom-routingtomtom-static-maptomtom-traffictomtom-waypoint-routingScored across 17 tools
The five search tools (fuzzy-search, poi-search, nearby, area-search, ev-search) overlap conceptually, but their descriptions explicitly delimit each: location bias vs. radius vs. strict geometry vs. EV-specific, and poi-categories is clearly a code-lookup prerequisite. The map tools (dynamic-map vs. data-viz) are likewise explicitly contrasted (a few markers/polygons vs. heatmaps/clusters/large GeoJSON). A few internal app tools (get-app-data, report-app-status) are less clearly separated from the user-facing flow, keeping it from a 5.
All names share the uniform 'tomtom-' kebab-case prefix, giving a predictable family. However, the suffix style mixes bare nouns (routing, traffic) with verb-noun/verb-phrases (search-along-route, fuzzy-search, area-search, get-api-key), so the action isn't always encoded in the same position. Readable and consistent enough, with a minor stylistic deviation.
17 tools is on the heavy edge of the ideal band, but a mapping/traffic/geocoding domain genuinely needs multiple search modes, geocoding, routing, traffic, EV, and visualization. The four internal app-plumbing tools (get-api-key, get-app-config, get-app-data, report-app-status) add surface area that is irrelevant to most agent workflows, slightly bloating the set.
Core lifecycle is well covered: bidirectional geocoding, multiple constrained search modes plus category-code lookup, multi-stop routing, traffic incidents, EV search, and two visualization tools. Gaps exist for a mapping domain—no distance/time matrix, isochrone/reachable-range, or waypoint optimization—but these are minor relative to the stated live-traffic/navigation purpose.
Routing, geocoding, places, matrix and map tools for location-aware AI workflows.
Geocoding, routing, isochrones, traffic, weather, and place search for AI agents. 19 MCP tools.
Provides AI assistants with direct access to Mapbox developer APIs and documentation.
TomTom MCP — wraps the TomTom Search & Routing APIs (api.tomtom.com)
