Skip to main content
Glama

openstreetmap-mcp-server

Find OSM features near a point

openstreetmap_query_nearby
Read-onlyIdempotent

Find OSM features within a radius around a geographic point via the Overpass API. The primary tool for "what's near X?" spatial queries. Use amenity for common POI types (hospital, pharmacy, restaurant, cafe, school, atm, 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. Results include all element types specified (nodes cover standalone POIs, ways cover buildings and areas), each with its full OSM tag set, sorted nearest-first by distance_meters from the center point. The extratags flag is not needed here — it applies only to the Nominatim-backed openstreetmap_search_places, openstreetmap_reverse_geocode, and openstreetmap_lookup_objects tools.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latYesCenter latitude in WGS84 decimal degrees.
lonYesCenter longitude in WGS84 decimal degrees.
limitNoMaximum results to return. Applied after the Overpass query — if the area has more features, they are truncated.
offsetNoNumber of matching features to skip before applying limit, for paging through a large result set. Features are distance-sorted before paging, so higher offsets return progressively farther matches; the full set is cached ~10 minutes so re-paging costs no extra upstream request. Pass the nextOffset value from a prior truncated response.
amenityNoOSM amenity tag value (e.g., "hospital", "pharmacy", "restaurant", "school", "atm"). Shortcut for tag_key="amenity". Cannot be combined with tag_key/tag_value.
tag_keyNoOSM tag key for non-amenity queries (e.g., "leisure", "shop", "highway", "natural"). Use with tag_value. Cannot be combined with amenity.
tag_valueNoOSM tag value paired with tag_key (e.g., "park", "supermarket", "primary", "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 like large campuses. Omit the field to search nodes and ways; an empty array is rejected because it can only match nothing.
radius_metersNoSearch radius in meters. Max 50,000m (50km). Keep under 5,000m for dense urban POI queries to avoid slow responses.
timeout_secondsNoOverpass query timeout in seconds. Increase for large radius 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 larger radius or different 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, up to the limit.
truncatedNoTrue if results were cut at the limit. Reduce radius, 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.9/5.0
Behavior5/5

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

Annotations provide readOnlyHint, openWorldHint, and idempotentHint, but the description adds substantial behavioral context beyond that: result sorting (nearest-first by distance_meters), inclusion of full OSM tag sets, behavior with element types (nodes vs ways), truncation via limit after the Overpass query, paging with offset and distance-sorted order, and a ~10-minute cache for re-paging. It also explicitly notes extratags is not needed here, preventing confusion with sibling tools. These details far exceed the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single, well-structured paragraph that front-loads the core purpose, then covers usage modes, result behavior, and tool differentiation. Each sentence conveys necessary information without redundancy. It ends with a clear note on the extratags flag that prevents misuse. No wasted words, and the structure follows a logical flow from purpose to usage to exclusions.

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?

Despite 10 parameters and an output schema (which isn't shown), the description covers all essential behavioral aspects: how filtering works, exactly one filter requirement, element types, sorting, pagination, cache behavior, and performance guidance for radius. It also clarifies relationships with sibling tools. Nothing an agent needs to correctly invoke this tool is omitted, and the output schema covers return structure.

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?

The input schema covers all 10 parameters with detailed descriptions (100% schema description coverage), so the baseline is 3. The description adds value by providing real-world examples (e.g., 'leisure=park', 'shop=supermarket'), clarifying the choice between amenity and tag_key/tag_value, and explaining element_types semantics (nodes for standalone POIs, ways for buildings). It also warns about radius limits for dense urban areas, which is not in the schema. This enrichment justifies a 4.

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 states a specific verb-resource pair: 'Find OSM features within a radius around a geographic point via the Overpass API.' It explicitly identifies itself as 'The primary tool for "what's near X?" spatial queries,' which distinguishes it from sibling tools like openstreetmap_query_bbox and openstreetmap_search_places. The filtering modes (amenity or tag_key/tag_value) are clearly explained, leaving no ambiguity about what the tool does.

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?

The description gives explicit guidance on when to use this tool vs alternatives: it declares itself the primary spatial point-radius tool and clarifies that the extratags flag applies only to other Nominatim-backed tools. It also tells agents to use amenity for common POIs or tag_key/tag_value for other categories, and states that exactly one of these must be provided. This is explicit when/when-not/alternatives guidance.

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.