MapMap

reachable_area

Compute the area reachable from an origin within one or more travel-time budgets, walkability/cyclability rings. Costing "pedestrian" answers "how far can I walk in 15 minutes?", "bicycle" the cycling equivalent; "auto", "truck" and "motor_scooter" work too (e.g. delivery coverage). contours_minutes lists the ring boundaries in minutes (1 to 4 values, each up to 120); set polygons true for filled polygons ready to render as a map fill layer instead of contour lines. Returns a GeoJSON FeatureCollection, one feature per contour. The origin is first moved onto the nearest road the travel mode can use (ferries excluded, at most 5 km away) and the rings are drawn from there: snapped_origin {lat, lon, distance_m} on the collection and on every feature's properties says where. An origin with no road within 5 km (open sea, desert, an unmapped area) is refused with "no roads near this point" rather than answered with a speck, and that refusal is not billed; move it onto land near a road. Optional exclude_polygons for before/after scenarios ("close this bridge and recompute reachability"): an array of polygons, each an array of [lon, lat] pairs forming one ring, longitude FIRST, whose intersecting roads are excluded from the reachability search. Applies to the Valhalla engine; unsupported on the GraphHopper engine, where it is ignored.

Input Schema

Name	Required	Description	Default
`origin`	Yes	Origin the reachable area is computed from.
`costing`	No	Travel mode: "auto" (default), "truck", "bicycle", "pedestrian" or "motor_scooter".	auto
`polygons`	No	Return filled polygons instead of contour linestrings (default false). Polygons draw directly as a MapLibre fill layer.
`contours_minutes`	Yes	Contour boundaries in minutes of travel time, e.g. [5, 10, 15] for 5/10/15-minute rings. 1 to 4 values (the routing engine's limit), each between 0 and 120 minutes.
`exclude_polygons`	No	Areas to avoid, scenario analysis ("close this bridge and recompute reachability"): an array of polygons, each an array of `[lon, lat]` pairs forming one exterior ring (GeoJSON-style, longitude FIRST). Roads intersecting any ring are excluded from the reachability search. Applies to the Valhalla engine; unsupported on the GraphHopper engine, where it is ignored.

Output Schema

Name	Required	Description	Default
`geojson`	Yes	GeoJSON FeatureCollection of the reachability contours, one feature per requested minute value (each feature's `contour` property is its minutes), as returned by the routing engine, drawn from the origin snapped onto the nearest usable road: the collection's `snapped_origin` `{lat, lon, distance_m}` (repeated on every feature's properties) says where that was.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

changedOutput schema / properties / geojson / description

Previous value: -"GeoJSON FeatureCollection of the reachability contours, one\nfeature per requested minute value (each feature's `contour`\nproperty is its minutes), as returned by the routing engine."New value: +"GeoJSON FeatureCollection of the reachability contours, one\nfeature per requested minute value (each feature's `contour`\nproperty is its minutes), as returned by the routing engine, drawn\nfrom the origin snapped onto the nearest usable road: the\ncollection's `snapped_origin` `{lat, lon, distance_m}` (repeated on\nevery feature's properties) says where that was."

Changed1 schema field changedOct 19, 2026

changedInput schema / properties / contours_minutes / description

Previous value: -"Contour boundaries in minutes of travel time, e.g. [5, 10, 15]\nfor 5/10/15-minute rings. 1–10 values, each between 0 and 120\nminutes."New value: +"Contour boundaries in minutes of travel time, e.g. [5, 10, 15]\nfor 5/10/15-minute rings. 1 to 4 values (the routing engine's\nlimit), each between 0 and 120 minutes."

Changed1 schema field changedOct 17, 2026

changedInput schema / properties / exclude_polygons / description

Previous value: -"Areas to avoid — scenario analysis (\"close this bridge and\nrecompute reachability\"): an array of polygons, each an array of\n`[lon, lat]` pairs forming one exterior ring (GeoJSON-style,\nlongitude FIRST). Roads intersecting any ring are excluded from\nthe reachability search. Applies to the Valhalla engine;\nunsupported on the GraphHopper engine, where it is ignored."New value: +"Areas to avoid, scenario analysis (\"close this bridge and\nrecompute reachability\"): an array of polygons, each an array of\n`[lon, lat]` pairs forming one exterior ring (GeoJSON-style,\nlongitude FIRST). Roads intersecting any ring are excluded from\nthe reachability search. Applies to the Valhalla engine;\nunsupported on the GraphHopper engine, where it is ignored."

Changed5 schema fields changedSep 23, 2026

addedInput schema / $defs / LatLon / anyOf

Added value: +[
+  {
+    "properties": {
+      "lat": {
+        "description": "Latitude in decimal degrees (−90 to 90).",
+        "format": "double",
+        "type": "number"
+      },
+      "lon": {
+        "description": "Longitude in decimal degrees (−180 to 180).",
+        "format": "double",
+        "type": "number"
+      }
+    },
+    "required": [
+      "lat",
+      "lon"
+    ],
+    "type": "object"
+  },
+  {
+    "description": "GeoJSON position [lon, lat]: longitude FIRST.",
+    "items": {
+      "format": "double",
+      "type": "number"
+    },
+    "maxItems": 2,
+    "minItems": 2,
+    "type": "array"
+  }
+]

changedInput schema / $defs / LatLon / description

Previous value: -"A WGS84 coordinate pair in decimal degrees."New value: +"A WGS84 coordinate in decimal degrees: a {lat, lon} object (preferred), or a GeoJSON [lon, lat] array with LONGITUDE FIRST, the same order as every polygon field on this server."

removedInput schema / $defs / LatLon / properties

Removed value: -{
-  "lat": {
-    "description": "Latitude in decimal degrees (−90 to 90).",
-    "format": "double",
-    "type": "number"
-  },
-  "lon": {
-    "description": "Longitude in decimal degrees (−180 to 180).",
-    "format": "double",
-    "type": "number"
-  }
-}

removedInput schema / $defs / LatLon / required
```
Removed value: -[
-  "lat",
-  "lon"
-]
```
removedInput schema / $defs / LatLon / type
```
Removed value: -"object"
```

First observedSep 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers: origin snapping to the nearest usable road (ferries excluded, 5 km cap), snapped_origin reporting on collection and features, the refusal case 'no roads near this point' with the notable detail that it is not billed, and engine applicability (Valhalla-only, ignored on GraphHopper). These are exactly the behaviors an agent cannot infer from 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.

Conciseness4/5

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

Purpose and primary parameters are front-loaded, and most sentences earn their place by adding behavioral detail. It is dense and long for a single paragraph, and the exclude_polygons engine caveat is echoed twice, which slightly dilutes the structure.

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?

For a complex spatial tool with 5 parameters, required fields, and an output schema already covering return values, the description still supplies all the preconditions an agent needs: snapping, refusal semantics, engine support, and output feature granularity (one feature per contour). Nothing essential is missing.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the before/after scenario rationale for exclude_polygons ('close this bridge and recompute'), the longitude-first ring convention, and the polygons true/false render-layer distinction. It goes past restating the schema rather than just duplicating it.

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 opens with a precise verb+resource: 'Compute the area reachable from an origin within one or more travel-time budgets.' It further grounds this with concrete framing (walkability/cyclability rings, isochrone-style output) that separates it from geometric siblings like geo_area, geo_bbox or geo_length.

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 strong contextual guidance via concrete questions ('how far can I walk in 15 minutes?', delivery coverage) and explains what each costing selects. However, it names no alternative sibling tool or an explicit when-not-to-use condition (e.g. single-point routing should use route instead), so it stops short of full routing guidance.

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

All MapMap tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?