Skip to main content
Glama

openstreetmap-mcp-server

Find OSM features within a bounding box

openstreetmap_query_bbox
Read-onlyIdempotent

Find OSM features within a rectangular geographic area (bounding box) via the Overpass API. Useful for area surveys where you want everything in a region, not proximity searches. Use amenity for common POI types (hospital, pharmacy, cafe, school, etc.) or tag_key + tag_value for other OSM categories (leisure=park, shop=supermarket, natural=peak). Exactly one of amenity or tag_key/tag_value must be provided. Every feature includes its full OSM tag set; the extratags flag (used by the Nominatim-backed openstreetmap_search_places, openstreetmap_reverse_geocode, and openstreetmap_lookup_objects tools) does not apply here. For proximity searches centered on a point, use openstreetmap_query_nearby instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eastYesEastern boundary longitude (maximum longitude). A value below west describes an antimeridian crossing rather than an inverted box.
westYesWestern boundary longitude (minimum longitude). A west greater than east is valid, not an error: Overpass reads it as an antimeridian-crossing box and returns the union of west..180 and -180..east.
limitNoMaximum results to return. Applied after the Overpass query — if the area has more features, they are truncated.
northYesNorthern boundary latitude (maximum latitude).
southYesSouthern boundary latitude (minimum latitude).
offsetNoNumber of matching features to skip before applying limit, for paging through a large result set. The full match set is fetched and cached ~10 minutes keyed by the query, so re-paging at a new offset is deterministic and costs no extra upstream request. Pass the nextOffset value from a prior truncated response.
amenityNoOSM amenity tag value shortcut (e.g., "cafe", "bench", "hospital"). Cannot be combined with tag_key/tag_value.
tag_keyNoOSM tag key for non-amenity queries (e.g., "leisure", "shop", "natural"). Use with tag_value. Cannot be combined with amenity.
tag_valueNoOSM tag value paired with tag_key (e.g., "park", "supermarket", "peak").
element_typesNoOSM element types to search, at least one. Ways cover most buildings and areas; nodes cover most standalone POIs. Add "relation" for complex structures. Omit the field to search nodes and ways; an empty array is rejected because it can only match nothing.
timeout_secondsNoOverpass query timeout in seconds. Increase for large bounding boxes or dense areas.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when the page came back empty. Distinguishes a query that matched nothing (try a different bounding box or tag) from an offset past the end of a non-empty result set (retry at a lower offset). Absent when results were returned.
elementsNoMatching OSM features within the bounding box, up to the limit.
truncatedNoTrue if results were cut at the limit. Reduce bbox area, add more specific tags, or page with offset to retrieve the rest.
nextOffsetNoOffset to pass on the next call to retrieve the following page of features. Present only when more features remain beyond this page.
totalFoundNoTotal features returned by Overpass before limit truncation.
attributionNoRequired data attribution: Data © OpenStreetMap contributors, ODbL 1.0.
effectiveTagNoThe OSM tag filter applied (key=value, e.g. "amenity=cafe" or "leisure=park").
data_timestampNoOSM data freshness timestamp from the Overpass response. Absent when the endpoint reported no freshness metadata.
servingEndpointNoOverpass endpoint that produced this response, as origin and path. Differs from the first configured endpoint when a mirror answered after the primary failed, and names the endpoint that served a cached response rather than the one this call would have tried. Pair it with data_timestamp when a result looks unexpectedly slow, sparse, or stale.

TDQS

A4.6/5.0
Behavior4/5

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

Annotations (readOnlyHint, openWorldHint, idempotentHint) already signal safe, deterministic behavior. The description adds valuable operational context: it notes the Overpass backend, that features include full OSM tag sets, clarifies the extratags flag is not applicable (unlike sibling tools), and explains the 10-minute deterministic paging cache. This goes beyond the annotations without contradicting them.

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 description is compact for a tool with 11 parameters. It front-loads the primary purpose and then packs each sentence with targeted information (alternatives, parameter selection, paging, extratags). While not minimal, every sentence earns its place, and the structure flows logically from purpose to usage to caveats.

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?

Given the tool's complexity (11 params, output schema present), the description is thorough. It covers the query mode choices, boundary semantics including antimeridian, element type guidance, limit/offset paging determinism, timeout advice, and differentiators from sibling tools. Combined with a full output schema, an agent has everything needed to call this correctly.

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% and each parameter has a detailed description, so the baseline is 3. The description adds semantic value by explicitly stating the 'exactly one of amenity or tag_key/tag_value' constraint (reinforcing the schema's anyOf), explaining that antimeridian crossing is valid, and describing how offset/limit and paging caching work. This aids correct invocation beyond the schema alone.

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 statement: 'Find OSM features within a rectangular geographic area (bounding box) via the Overpass API.' It immediately distinguishes area surveys from proximity searches and names the sibling tool (openstreetmap_query_nearby) as the alternative, making its scope unmistakable.

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?

Explicit usage guidance is provided: 'Useful for area surveys where you want everything in a region, not proximity searches' and 'For proximity searches centered on a point, use openstreetmap_query_nearby instead.' It also explains the selection between amenity and tag_key/tag_value, clarifying exclusivity and giving examples. This fully covers when and when not to use the tool.

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.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct operation: lookup by ID, bbox query, proximity query, raw Overpass, reverse geocode, and place search. Descriptions explicitly cross-reference when to use each, leaving no ambiguity.

Naming Consistency5/5

All tools follow a consistent openstreetmap_<verb>_<object/qualifier> pattern in snake_case, with clear verb choices (lookup, query, reverse, search) and a coherent query_* subfamily.

Tool Count5/5

Six tools is ideal for a read-only OSM server, covering geocoding, spatial queries, ID lookup, and raw Overpass without redundancy.

Completeness5/5

The surface covers the full lifecycle of geospatial lookups: name-to-coordinates, coordinates-to-address, ID-to-details, area/radius searches, and arbitrary raw queries, with no obvious gaps for the intended domain.