Skip to main content
Glama

map_viewport

Get what to draw for one map view: clusters, pins, or named pins.

Send the view as `bbox`, or as `lat` + `lng` + `radius_miles`. The detail
returned depends on the zoom the view is answered at (the response states it
in `zoom`):
  - zoom 3-12  -> mode 'clusters': a count per grid cell. Each cluster has
    `count`, `bbox`, `breakdown` and `expansionZoom` (fit the map to `bbox` at
    that zoom and the cluster comes apart).
  - zoom 13-14 -> mode 'pins': one pin per address, position only, no name.
  - zoom 15+   -> mode 'markers': pins with `label` (first initial and last
    name), `housingStatus`, `hasPhoto`, `registryState`.
A close view holding more than 300 pins is answered as clusters instead.

Returns: { mode, zoom, bbox, datasetVersion, total, breakdown {street, housed,
homeless, incarcerated}, clusters[], markers[], areas[], unplaced {count,
states}, notice }. In radius mode also `center`, `radiusMiles` and
`withinRadius` (exact), and each marker has `distanceMiles`.
  - 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;
    each has a `groupId` too. Never describe them as being at an exact spot.
  - `unplaced` counts people in the states this view touches who have no
    mappable address. Mention it rather than implying the map shows everyone.
  - 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 view holds. Marker and group
ids work for 24 hours. The Map API must be turned on for the account
(the API answers 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
latNoLatitude of the centre, instead of bbox (send with lng and radius_miles).
lngNoLongitude of the centre, instead of bbox (send with lat and radius_miles).
bboxNoThe view as 'west,south,east,north' in degrees, e.g. '-83.5,39.6,-82.4,40.3'. Any size. Send this OR lat/lng with radius_miles, not both.
zoomNoOptional map zoom, 0 to 22. Decides the detail: 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 view.
detailNofull = clusters or pins (default); count = numbers only.full
housingNoKeep only people with one of these housing statuses.
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.
radius_milesNoRadius in miles around lat/lng, 0.1 to 100.

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?

No annotations are provided, so the description carries the full burden and does so richly: per-call billing ($2/1,000), 24-hour id validity, the 403 map_not_enabled dependency and the sandbox bypass, the >300-pin downgrade rule, and the caveat that pins are registered addresses rather than current locations (reinforced by the `notice` field). This is far beyond a bare mutation/read disclosure.

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 is front-loaded in the first sentence, then structured into view-spec, zoom modes, return shape, and billing/auth sections with compact bullets. It is long, but nearly every line conveys actionable detail; only minor redundancy between the zoom bullet and the schema's own zoom description.

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 9-parameter tool with no output schema and no annotations, the description fully compensates: it documents the response envelope field-by-field, the mode-dependent shape, the areas/unplaced edge cases, and auth/billing constraints. An agent has everything needed to call it and interpret the result.

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 adds semantics the schema does not: the zoom-to-mode mapping table, the radius-mode return differences, and especially the >300-pin clustering override. It also explains how to interpret `id: null` markers with a `groupId`, which is behavioral meaning layered on the parameters.

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 ('Get what to draw for one map view') and immediately enumerates the three output modes (clusters, pins, named pins). It also names siblings map_group and map_open_record in the context where they apply, so an agent can distinguish this tool from the family without opening a schema.

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 two mutually-exclusive ways to specify the view (bbox OR lat+lng+radius_miles) and routes sub-cases to siblings ('call map_group with that groupId', 'call map_open_record with its id'). It lacks an explicit when-not-this-tool statement against siblings like map_area or map_route, but the context needed to invoke correctly is present.

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.