Skip to main content
Glama
tomtom-international

TomTom MCP Server

Official

TomTom Static Map

tomtom-static-map
Read-onlyIdempotent

Generate custom map images with chosen center, zoom, style, and size for embedding in apps or documents.

Instructions

Generate custom map images from TomTom Maps with specified center coordinates, zoom levels, and style options

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bboxNoBounding box in format [west, south, east, north]. Alternative to center+zoom. Example: [-122.42, 37.77, -122.40, 37.79] for part of San Francisco.
viewNoGeopolitical view for border disputes and territories. 'Unified' is the international standard view.
zoomNoZoom level (0-22). Examples: 3 (continent), 6 (country), 10 (city), 15 (neighborhood), 18 (street). Default: 15.
layerNoMap layer type: 'basic' (streets), 'labels' (text only, transparent background), 'hybrid' (satellite with labels).
styleNoMap style: 'main' (default daytime), 'night' (dark theme).
widthNoMap width in pixels (50-2048). Examples: 300-500 (preview), 800-1200 (detailed). Default: 512.
centerYesMap center coordinates. Use results from geocoding or search operations for best positioning.
formatNoImage format: 'png' (better quality, supports transparency), 'jpg' (smaller file size).
heightNoMap height in pixels (50-2048). Examples: 300-500 (preview), 800-1200 (detailed). Default: 512.
languageNoLanguage for map labels (IETF language tag). Examples: 'en-US', 'es-ES', 'fr-FR'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.8
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / center / additionalProperties
      Removed value: -false
  2. First observedv1.0.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it generates images but doesn't disclose details like rate limits, image size limits beyond schema, or behavior when both bbox and center are provided. It doesn't contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core purpose. It's efficient and doesn't waste words, though it could benefit from a brief usage note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 10 parameters and no output schema, the description is adequate but not complete. The schema covers parameters well, but the description doesn't explain return values (image format details), potential conflicts between bbox and center, or when to prefer this over tomtom-dynamic-map. The annotations cover safety, but behavioral context is thin.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds a general overview but doesn't provide additional meaning beyond what the schema already covers. Baseline 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: generating custom map images from TomTom Maps with center coordinates, zoom levels, and style options. It distinguishes it from sibling tools like geocoding or routing, though it doesn't explicitly differentiate from the closely related tomtom-dynamic-map sibling.

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

Usage Guidelines3/5

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

The description implies usage for generating static map images but provides no explicit guidance on when to choose this tool over tomtom-dynamic-map or other alternatives. The parameter descriptions offer some context (e.g., using geocoding results for center), but there's no direct when-to-use or when-not-to-use guidance.

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