Skip to main content
Glama
tomtom-international

TomTom MCP Server

Official
by tomtom-international
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

TomTom Area Search

tomtom-area-search
Read-onlyIdempotent

Find points of interest strictly inside a polygon, bounding box, or circle so results are confined to the specified geographic boundary.

Instructions

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'.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of results (1-100). Default: 10.
queryYesWhat to search for in the area. Examples: 'restaurant', 'hotel', 'parking', 'pharmacy', 'ATM'.
centerNoCenter position as [longitude, latitude] for circular area search (GeoJSON convention). Use with radius. Example: [4.89707, 52.377956] for Amsterdam.
radiusNoRadius in meters for circular area search. Required with center. Examples: 500, 1000, 5000.
polygonNoPolygon vertices as [[longitude, latitude], ...] (GeoJSON convention). Minimum 3 points, automatically closed. Use instead of center/radius for irregular areas.
show_uiNoRequest the interactive map widget. Only hosts that support MCP Apps render it. It adds no coordinates to the text response. Default: false
languageNoLanguage for results (IETF tag). Examples: 'en-US', 'de-DE'.
boundingBoxNoRectangular 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.
poiCategoriesNoFilter 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_detailNoResponse 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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.13

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools