Maps by DeltaBreen

isochrone

Read-only

The areas reachable from a point within given travel times (up to four, 1 to 60 minutes each) by car, truck, bike or on foot, as GeoJSON polygons in the shape of Mapbox Isochrone v1, one feature per time with its contour in minutes. For a store's catchment, a 15-minute walk, or who can reach an address in half an hour. Times assume normal road speeds. Counts one lookup against the workspace's monthly searches, on every plan; past the plan it returns searches_exhausted and nothing is charged. Show the returned attribution with the areas.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "lng": "<lng>",
      "lat": "<lat>",
      "minutes": "<minutes>"
    },
    "name": "isochrone"
  }
}

Input Schema

Name	Required	Description
`lat`	Yes	Latitude of the starting point, -90 to 90.
`lng`	Yes	Longitude of the starting point, -180 to 180.
`key_id`	No	The map key (uuid from list_keys) to count the lookup against. Default: the workspace's first active secret key, else its first publishable one.
`minutes`	Yes	Travel times in whole minutes, up to four, each 1 to 60 (e.g. [10, 20, 30]).
`profile`	No	driving (the default), driving-hgv (a truck), cycling or walking.
`polygons`	No	Areas as polygons (the default) or as their outlines only.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses billing behavior, plan exhaustion behavior, the searches_exhausted response, and the attribution requirement. These are operationally important details an agent would not otherwise know.

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?

The description front-loads the tool's output and scope, then adds operational caveats and billing context. Every sentence contributes useful information, and there is no redundant or filler text.

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

Completeness5/5

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

With no output schema, the description still explains the return format clearly: GeoJSON polygons, one feature per time, contour in minutes. It also covers assumptions, billing, and attribution, which are exactly the missing pieces an agent would need.

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 input schema already documents lat, lng, minutes, profile, polygons, and key_id. The description restates the key constraints (up to four times, 1–60 minutes, travel modes, polygons default) but adds little beyond 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?

The description precisely defines the resource: reachable areas from a point within travel times, returned as GeoJSON polygons in Mapbox Isochrone v1 format with one feature per contour. This is clearly distinct from route/distance siblings like directions and distance_matrix.

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

Usage Guidelines4/5

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

It gives concrete usage examples such as store catchments, 15-minute walks, and half-hour reachability, which clarifies when the tool is appropriate. However, it does not explicitly state when to choose alternatives like directions or distance_matrix instead.

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

All Maps by DeltaBreen tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?