Skip to main content
Glama

map_route

Exact counts of registered addresses along one walking or bus route.

Counts a corridor either side of the line, a radius around each stop, or
both, and returns exact numbers per leg and per stop with nameless pins and
their distances. Never an estimate and never partial: the answer is complete
or the call fails without a charge.

Returns: { shape: 'route', profile, measure, detail, datasetVersion, complete,
lengthMiles, corridorMiles, stopRadiusFeet, parcelAllowanceFeet, units,
total, corridorTotal, stopsTotal, breakdown {street, housed, homeless,
incarcerated}, legs: [ {leg, fromStop, toStop, lengthMiles, count} ],
stops: [ {stopId, alongMiles, count, nearestFeet, markerIds} ],
markers: [ {id, lat, lng, precision, addressType, distanceMiles, leg,
alongMiles, nearestStop, stopDistanceFeet} ], groups[], approximate {count,
areas[]}, unplaced {count, states}, externalId, notice, routeNotice }.
  - `total` = distinct people with a street address in the corridor or a
    stop's reach; leg counts sum to `corridorTotal`.
  - Pins carry NO NAMES. A `groups` entry (several people at one address) and
    an `approximate.areas` entry (people placed only at the middle of a ZIP,
    city or county; never in `total`) open with map_group.
  - To see who one marker is, call map_open_record with its `id` — a
    separate charge at the account's record-open rate (published price
    $0.035 per open; an account's agreed rate may differ). Open only the
    records the user asks for, not every marker on the route.
  - More than 300 pins at detail=full is a 422 `route_too_many_people` that
    carries the exact counts and is not charged: use detail='count' or split
    the route.

A count shows REGISTERED ADDRESSES, NOT WHERE ANYONE IS, and is not a rating
of the route. Never describe a route as safe or unsafe; relay `notice` and
`routeNotice`. It supports the user's process; it is not a legal
determination.

Billing: route units, each one map request ($2 per 1,000): one per started
mile of measured corridor plus one per 10 stops when stop radii are measured
(minimum 1); `units` in the answer says how many. detail='count' costs the
same. E.g. a 17.4-mile bus route with 35 stops = 18 + 4 = 22 units. Test
mode is free. The Map API must be turned on for the account.

Auth: uses the caller's X-API-Key (request header or OFFENDERSEARCH_API_KEY env).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoThe route line: a GeoJSON LineString {'type':'LineString','coordinates':[[lng,lat],...]} (or a Feature holding one), or a plain list [[lng, lat], ...] in GeoJSON order. Send at most one of path or polyline.
stopsNoStops along the route, in order: [{'id':'s1','lng':...,'lat':...}, ...] or [[lng, lat], ...]. Ids default to s1, s2, .... With no path or polyline, 2+ stops are joined by straight lines. Walk: up to 50 stops; bus: up to 150.
detailNofull = counts plus nameless pins (default); count = counts only, same price, never refused for too many pins.full
housingNoKeep only people with one of these housing statuses.
measureNoWhat to count: the corridor either side of the line, a radius around each stop, or both. Default: both when stop_radius_feet is sent, otherwise corridor (stops when there is no line and fewer than 2 stops).
profileNowalk (default; up to 15 miles, stop radius 500 ft) or bus (up to 60 miles, stop radius 1,000 ft).
sandboxNoIf true, answer in test mode: made-up people in the real response shape. Needs no plan and is never billed.
polylineNoThe route line as an encoded polyline (Google = precision 5; Mapbox/OSRM/Valhalla = precision 6), instead of path.
external_idNoYour own reference for this route (up to 100 characters), echoed back as `externalId`.
street_onlyNoIf true, keep only people with an exact street address.
corridor_milesNoCorridor width either side of the line, in miles, 0.02 to 0.25 (default 0.1).
stop_radius_feetNoRadius around each stop, in feet, 100 to 2,640 (default walk 500, bus 1,000).
polyline_precisionNoPrecision of `polyline`: 5 (Google, the default) or 6 (Mapbox/OSRM/Valhalla).
parcel_allowance_feetNoFeet added to the stop radius, 0 to 500, to allow for the distance between a geocoded point and the property line.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations at all, the description carries the full burden and does so richly: billing formula with a worked example ($2/1,000, 22 units for a 17.4-mile/35-stop route), free test mode, auth via X-API-Key/OFFENDERSEARCH_API_KEY, that the call is all-or-nothing and failure is uncharged, the 422 route_too_many_people behavior, and that pins are nameless. The ethical constraints (registered addresses, not where anyone is; never call a route safe/unsafe; relay notice) are unusually valuable context.

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 opening sentence and the measure explanation are front-loaded, and the billing/auth blocks are clearly quarantined at the end. It is long, and the full return-shape enumeration is dense, but with no output schema that enumeration is load-bearing rather than padding.

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 14-parameter geospatial tool with no annotations and no output schema, the description supplies purpose, parameter semantics, a complete return shape, failure modes, billing, auth, and the cross-tool handoffs to map_group and map_open_record. Nothing an agent needs to call it correctly or interpret the answer 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 coverage is 100% so the baseline is 3, but the description goes beyond it: it clarifies that detail='count' costs the same as full, that measure defaults to both when stop_radius_feet is sent and corridor otherwise, and that profile bounds the corridor length and stop radius. It does not restate corridor_miles or parcel_allowance_feet semantics, but the added meaning is genuine.

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?

Opens with a specific verb, resource and scope: 'Exact counts of registered addresses along one walking or bus route.' This pins the tool as a route-corridor counter, which separates it from area/vantage siblings like map_area and map_viewport, and the map_open_record cross-reference clarifies its boundary further.

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?

Gives explicit condition-action pairs: use detail='count' or split the route when over 300 pins, call map_open_record only for markers the user actually asks about, and it explains profile/measure selection. It stops short of explicitly contrasting map_route with map_area or map_viewport for non-route geometries, so the sibling routing is implied rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.