Skip to main content
Glama

map_area

Get what to draw inside a drawn shape: a polygon, or a line with a buffer.

The same answer as map_viewport for the shape's bounding box, limited to what
is inside the shape, at the same detail levels (clusters, pins, or named pins
at zoom 15+). The response adds `shape: 'polygon' | 'route'`.

Returns: { shape, mode, zoom, bbox, datasetVersion, total, breakdown {street,
housed, homeless, incarcerated}, clusters[], markers[], areas[], unplaced
{count, states}, notice }.
  - A marker with `id: null` and a `groupId` stands for several people at one
    address: call map_group with that `groupId`.
  - `areas` are people placed only at the middle of a ZIP, city or county.
    Never describe them as being at an exact spot.
  - To see who one marker is, call map_open_record with its `id`.

A pin shows a REGISTERED ADDRESS, not a person's current location — say so
when you describe a result (`notice` carries the sentence).

Billing: one map request per call ($2 per 1,000), whatever the shape holds.
Marker and group ids work for 24 hours. The Map API must be turned on for the
account (403 `map_not_enabled` otherwise); `sandbox=true` works without it.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
zoomNoOptional map zoom, 0 to 22. Decides the detail as on map_viewport: 3-12 clusters, 13-14 pins without names, 15+ pins with names. Omit it and the zoom is worked out from the size of the shape.
detailNofull = clusters or pins (default); count = numbers only.full
housingNoKeep only people with one of these housing statuses.
polygonNoA ring of 3 to 200 [lng, lat] points (GeoJSON order: longitude first), e.g. [[-83.0,39.9],[-82.9,39.9],[-82.95,40.0]]. A repeated closing point is fine. Send this OR route_points, not both.
sandboxNoIf true, answer in test mode: made-up people (labels start with 'Sample') in the real response shape. Needs no plan and is never billed.
street_onlyNoIf true, keep only people with an exact street address.
buffer_milesNoDistance either side of route_points, in miles, 0.05 to 5.
route_pointsNoA line of 2 to 200 [lng, lat] points (GeoJSON order). Everyone within buffer_miles either side of it is counted. Send with buffer_miles, instead of polygon. For exact per-leg and per-stop counts along a walking or bus route use map_route.

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, the description carries the full burden and does so: billing ($2 per 1,000, one request per call regardless of shape size), 24-hour id lifetime, the 403 map_not_enabled requirement, sandbox mode that bypasses the plan, and auth via X-API-Key. It also warns that a pin is a REGISTERED ADDRESS, not a current location, and that `areas` are ZIP/city-level placements that must not be described as exact spots.

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?

Front-loaded with the purpose sentence and then organized by concern (return shape, marker semantics, billing, auth), so a reader can stop early. The inline Returns block is long but justified because no output schema exists; only minor duplication of the schema's zoom semantics keeps it from a 5.

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 an 8-parameter, zero-required geospatial query with no output schema and no annotations, the description fills every gap an agent needs: return structure, id/groupId semantics, placement caveats, cost, auth, and the one notable failure mode. Nothing required to call it correctly is missing.

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 zoom, polygon, route_points, buffer_miles and the rest; that sets the baseline at 3. The description adds only marginal parameter meaning beyond it — the detail-level mapping (clusters/pins/named pins at zoom 15+) and the route_points/buffer_miles pairing are both already stated in the schema text.

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 and resource ('Get what to draw inside a drawn shape') and immediately scopes it to two shape types, polygon or buffered line. It explicitly contrasts itself with map_viewport ('the same answer ... limited to what is inside the shape'), so an agent can separate the two without reading either schema.

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?

Routes the agent to the right sibling for each sub-case: map_group for a marker with id null plus groupId, map_open_record to see who one marker is, and map_route for exact per-leg/per-stop counts. It also states the polygon-vs-route_points mutual exclusion, leaving nothing to inference.

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.