A
license-
qualityC
maintenanceEnables programmatic queries against the OpenStreetMap database using the Overpass API.
18
MIT
openstreetmap-mcp-server
Server Details
Geocode, reverse geocode, and run Overpass spatial queries on OpenStreetMap data.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/openstreetmap-mcp-server
- GitHub Stars
- 4
- Server Listing
- @cyanheads/openstreetmap-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.7/5.0
Tool DescriptionsA
Average 4.8/5 across 6 of 6 tools scored.
Server CoherenceA
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.
Available Tools
6 toolsopenstreetmap_lookup_objectsLook up address details for OSM objects by IDARead-onlyIdempotentInspect
Fetch address details for one or more known OSM objects by their IDs via Nominatim. Each ID must be prefixed with N (node), W (way), or R (relation), e.g., "N240109189", "W50637691", "R146656". Up to 50 IDs per call. Use when an OSM ID is already known from a prior openstreetmap_query_nearby or openstreetmap_query_bbox result — this is more efficient than a geocoding round trip to get the full Nominatim address record. The results are exactly the objects named in osm_ids: extratags decorates them and cannot select them, and there is no way to ask this tool for objects carrying a given tag. Discover such objects with openstreetmap_query_nearby, openstreetmap_query_bbox, or openstreetmap_query_raw, then pass their IDs here.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| osm_ids | Yes | OSM IDs to look up, each prefixed with N (node), W (way), or R (relation). Always an array, including for a single ID: ["N240109189"], ["W50637691", "R146656"]. Up to 50 IDs per call. | |
| language | No | Preferred language for names (BCP 47 code). | |
| extratags | No | Include the extra OSM tags each looked-up object carries — contact and metadata tags (phone, website, opening_hours, wikidata) and physical attribute tags alike (surface, tracktype, sac_scale, ele, access). Reports whatever the object happens to carry, so an absent tag describes that object rather than OpenStreetMap. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Number of results returned. |
| results | Yes | Address details for the requested OSM IDs that were found. |
| not_found | Yes | OSM IDs from the request that returned no result. |
| attribution | Yes | Required data attribution: Data © OpenStreetMap contributors, ODbL 1.0. |
| tagSelectionCaveat | No | Standing caveat: tag-based selection lives on the Overpass tools (openstreetmap_query_nearby, openstreetmap_query_bbox, openstreetmap_query_raw), never here. extratags decorates the returned objects rather than selecting them, so a missing tag is not evidence the tag is missing from OpenStreetMap. Present when extratags was requested. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that extratags only decorates results and cannot select objects, and that results are exactly the objects in osm_ids. Adds context about absent tags, which goes beyond the readOnly/idempotent/openWorld annotations. No contradiction.
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?
Every sentence earns its place. The purpose is front-loaded, followed by ID format, usage context, and limitations. Concise yet comprehensive for a tool with non-obvious ID prefixes and discovery flow.
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?
Covers the full workflow: discovery via siblings, then lookup by ID. Addresses potential misconceptions about extratags and tag-based selection. With an output schema present, not detailing return values is acceptable.
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 the description reinforces ID format, array usage, and limit. It adds behavioral nuance for extratags (decorates, cannot select) and clarifies that results cannot be filtered by tags, which supplements the schema descriptions.
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 clearly states the tool fetches address details for known OSM objects by ID via Nominatim. It distinguishes from sibling tools by specifying it is for known IDs, not discovery, and even names when to use it over geocoding.
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?
Explicitly states when to use: when an OSM ID is known from a prior query. Provides exclusions: cannot ask for objects by tag, and names alternatives: openstreetmap_query_nearby, openstreetmap_query_bbox, or openstreetmap_query_raw for discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openstreetmap_query_bboxFind OSM features within a bounding boxARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| east | Yes | Eastern boundary longitude (maximum longitude). A value below west describes an antimeridian crossing rather than an inverted box. | |
| west | Yes | Western 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. | |
| limit | No | Maximum results to return. Applied after the Overpass query — if the area has more features, they are truncated. | |
| north | Yes | Northern boundary latitude (maximum latitude). | |
| south | Yes | Southern boundary latitude (minimum latitude). | |
| offset | No | Number 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. | |
| amenity | No | OSM amenity tag value shortcut (e.g., "cafe", "bench", "hospital"). Cannot be combined with tag_key/tag_value. | |
| tag_key | No | OSM tag key for non-amenity queries (e.g., "leisure", "shop", "natural"). Use with tag_value. Cannot be combined with amenity. | |
| tag_value | No | OSM tag value paired with tag_key (e.g., "park", "supermarket", "peak"). | |
| element_types | No | OSM 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_seconds | No | Overpass query timeout in seconds. Increase for large bounding boxes or dense areas. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance 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. |
| elements | Yes | Matching OSM features within the bounding box, up to the limit. |
| truncated | Yes | True if results were cut at the limit. Reduce bbox area, add more specific tags, or page with offset to retrieve the rest. |
| nextOffset | No | Offset to pass on the next call to retrieve the following page of features. Present only when more features remain beyond this page. |
| totalFound | Yes | Total features returned by Overpass before limit truncation. |
| attribution | Yes | Required data attribution: Data © OpenStreetMap contributors, ODbL 1.0. |
| effectiveTag | Yes | The OSM tag filter applied (key=value, e.g. "amenity=cafe" or "leisure=park"). |
| data_timestamp | No | OSM data freshness timestamp from the Overpass response. Absent when the endpoint reported no freshness metadata. |
| servingEndpoint | No | Overpass 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. |
Tool Definition Quality
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that every feature includes its full OSM tag set and that the extratags flag—used by other tools—does not apply here, preventing cross-tool confusion. This is useful behavioral context beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, with the main purpose in the first sentence and subsequent sentences adding usage context and a cross-tool clarification. It is information-dense without redundancy, though the extratags sentence might be slightly tangential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, an output schema, and clear annotations, the description covers the central use case, provides explicit alternatives, and clarifies a key output behavior. Paging behavior is documented in the schema, so the description doesn't need to repeat it.
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?
The input schema provides 100% parameter coverage, including descriptions for each field and the anyOf constraint. The description reinforces the exclusive choice between amenity and tag_key/tag_value but doesn't add new syntax or format details beyond the schema.
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 'Find OSM features within a rectangular geographic area (bounding box) via the Overpass API,' which is a specific verb+resource+scope. It also distinguishes from proximity searches by name, making it clear which tool to use.
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?
It explicitly states when to use this tool: 'Useful for area surveys where you want everything in a region, not proximity searches.' It also names the alternative: 'For proximity searches centered on a point, use openstreetmap_query_nearby instead.' This is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openstreetmap_query_nearbyFind OSM features near a pointARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Center latitude in WGS84 decimal degrees. | |
| lon | Yes | Center longitude in WGS84 decimal degrees. | |
| limit | No | Maximum results to return. Applied after the Overpass query — if the area has more features, they are truncated. | |
| offset | No | Number 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. | |
| amenity | No | OSM amenity tag value (e.g., "hospital", "pharmacy", "restaurant", "school", "atm"). Shortcut for tag_key="amenity". Cannot be combined with tag_key/tag_value. | |
| tag_key | No | OSM tag key for non-amenity queries (e.g., "leisure", "shop", "highway", "natural"). Use with tag_value. Cannot be combined with amenity. | |
| tag_value | No | OSM tag value paired with tag_key (e.g., "park", "supermarket", "primary", "peak"). | |
| element_types | No | OSM 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_meters | No | Search radius in meters. Max 50,000m (50km). Keep under 5,000m for dense urban POI queries to avoid slow responses. | |
| timeout_seconds | No | Overpass query timeout in seconds. Increase for large radius or dense areas. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance 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. |
| elements | Yes | Matching OSM features, up to the limit. |
| truncated | Yes | True if results were cut at the limit. Reduce radius, add more specific tags, or page with offset to retrieve the rest. |
| nextOffset | No | Offset to pass on the next call to retrieve the following page of features. Present only when more features remain beyond this page. |
| totalFound | Yes | Total features returned by Overpass before limit truncation. |
| attribution | Yes | Required data attribution: Data © OpenStreetMap contributors, ODbL 1.0. |
| effectiveTag | Yes | The OSM tag filter applied (key=value, e.g. "amenity=cafe" or "leisure=park"). |
| data_timestamp | No | OSM data freshness timestamp from the Overpass response. Absent when the endpoint reported no freshness metadata. |
| servingEndpoint | No | Overpass 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. |
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses meaningful behavior: results include full OSM tag sets, are sorted nearest-first by distance_meters, and cover specified element types. It also reveals the Overpass API backend. While it doesn't mention caching or truncation details, those are covered in the schema, and the added context is substantive.
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 compact and front-loaded with the core purpose, then expands into selection guidance and result behavior. Every sentence contributes useful information without redundancy or fluff. It achieves high information density while remaining readable.
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?
With 10 parameters, an output schema, and annotations, the description covers the essential behavioral context: what counts as a match, how results are ordered, and how to choose filter parameters. The output schema handles return-value details, so the description does not need to repeat them. The guidance is sufficient for an agent to select and invoke the tool effectively.
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 real value by explaining the selection logic: exactly one of amenity or tag_key/tag_value must be provided, and it clarifies element_types semantics (nodes vs ways). It also disambiguates extratags as irrelevant to this tool, which helps parameter understanding.
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 specific verb and resource: 'Find OSM features within a radius around a geographic point via the Overpass API.' It clearly identifies the tool as 'The primary tool for "what's near X?" spatial queries,' which separates it from sibling tools like openstreetmap_query_bbox and openstreetmap_search_places.
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?
The description gives clear usage context: use this for radius-based spatial queries, with explicit guidance on choosing between amenity and tag_key/tag_value. It also notes that extratags applies only to other Nominatim-backed tools, which helps avoid misuse. However, it does not explicitly contrast with openstreetmap_query_bbox for bounding-box queries or openstreetmap_query_raw for raw Overpass queries, so exclusion guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openstreetmap_query_rawExecute a raw Overpass QL queryARead-onlyIdempotentInspect
Execute a raw Overpass QL query for advanced spatial queries that the convenience tools do not cover. Use for multi-type queries, union queries, relation membership, historical queries, or any operation requiring full Overpass QL expressiveness. The query must include [out:json]. Example: "[out:json][timeout:15];node"natural"="peak";out body;" Returns one page of the result set: use limit and offset to page through it, and read totalFound and truncated to see how much the query matched. Validate complex queries at overpass-turbo.eu before use. For simple "what's near X?" or "what's in this area?" queries, use openstreetmap_query_nearby or openstreetmap_query_bbox instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum elements to return. Applied after the Overpass query — if the query matched more, they are truncated. | |
| query | Yes | Overpass QL query string. Must include [out:json]. The server sets the endpoint and User-Agent; do not include those. Example: "[out:json][timeout:15];node[\"natural\"=\"peak\"](47.5,-122.5,47.7,-122.2);out body;" | |
| offset | No | Number of matching elements 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; a result over 100000 elements is served but not cached, so paging that far re-queries and depends on the endpoint returning the same order. Pass the nextOffset value from a prior truncated response. | |
| timeout_seconds | No | Query timeout in seconds, bounding how long Overpass itself spends on the query. The [timeout:N] directive in the query string takes precedence if present. The client waits for what is requested here, up to 180s, so a long-running query is not cut off early — but the endpoint enforces its own budget and may answer HTTP 504 first. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when the page came back empty. Distinguishes a query that matched nothing (check syntax or broaden the filter) from an offset past the end of a non-empty result set (retry at a lower offset). Absent when results were returned. |
| elements | Yes | Raw Overpass API response elements for this page, up to the limit. Structure varies by query type — nodes have lat/lon, ways have nodes[], relations have members[]. |
| truncated | Yes | True if elements were cut at the limit. Narrow the query, or page with offset to retrieve the rest. |
| nextOffset | No | Offset to pass on the next call to retrieve the following page of elements. Present only when more elements remain beyond this page. |
| totalFound | Yes | Total elements returned by Overpass before limit truncation. |
| attribution | Yes | Required data attribution: Data © OpenStreetMap contributors, ODbL 1.0. |
| data_timestamp | No | OSM data freshness timestamp from the Overpass response. Absent when the endpoint reported no freshness metadata. |
| effectiveQuery | Yes | The Overpass QL string as sent to the API (after any timeout injection). |
| total_elements | Yes | Number of elements returned on this page. See totalFound for the full match count. |
| servingEndpoint | No | Overpass 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. |
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds extensive behavior beyond readOnly/idempotent annotations: describes single-page returns, paging via limit/offset, totalFound/truncated fields, server-set endpoint/User-Agent, caching behavior with 10-minute key and >100k result exception, and timeout precedence. No contradiction with 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?
Dense but efficient; every sentence earns its place—purpose, usage, example, return semantics, validation tip, and alternatives. No redundancy or irrelevant detail, and it is well-structured front-loaded with the core purpose.
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 raw-query tool with four parameters and an output schema, it covers all essential aspects: when to use, constraints, paging, caching, timeout behavior, and alternatives. The description is complete and leaves no critical gaps for an agent to invoke and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers 100% of parameters; description significantly enriches them by specifying the [out:json] requirement, providing an example query, explaining offset's deterministic re-paging and caching, and clarifying timeout directive precedence. Far exceeds the baseline.
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?
Clearly states it executes raw Overpass QL queries for advanced spatial queries not covered by convenience tools, with specific use cases like multi-type and union queries. Distinguishes from sibling query tools via explicit contrast with simple-query counterparts.
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?
Explicitly says when to use (advanced operations requiring full Overpass QL) and when not to (simple 'what's near X?' queries → use openstreetmap_query_nearby or openstreetmap_query_bbox). Also advises validating complex queries at overpass-turbo.eu.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openstreetmap_reverse_geocodeReverse geocode coordinates to an addressARead-onlyIdempotentInspect
Convert latitude/longitude coordinates to the nearest address or place name via Nominatim/OpenStreetMap. Returns the closest matching OSM object at the given coordinates. Note: Nominatim finds the nearest indexed OSM object — in dense areas this may differ from the address at the exact coordinate. Use zoom=18 for building-level accuracy, lower zoom values for coarser resolution (e.g., zoom=10 for city-level). The match is made on proximity and layer, never on an OSM attribute tag: extratags decorates the matched object and cannot select one. To find the objects in an area that carry a given tag, use openstreetmap_query_nearby, openstreetmap_query_bbox, or openstreetmap_query_raw.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in WGS84 decimal degrees. | |
| lon | Yes | Longitude in WGS84 decimal degrees. | |
| zoom | No | Address detail level, roughly corresponding to map zoom. 18=building, 16=street, 14=neighbourhood, 12=town, 10=city, 8=county, 5=state, 3=country. | |
| layer | No | Restrict which OSM layer is matched. Comma-separated: address, poi, railway, natural, manmade. Default: address,poi. | |
| language | No | Preferred language for the result (BCP 47 code or Accept-Language string). | |
| extratags | No | Include the extra OSM tags the matched object carries — contact and metadata tags (phone, website, opening_hours, wikidata) and physical attribute tags alike (surface, tracktype, sac_scale, ele, access). Opportunistic, not selective: it reports whatever the matched object happens to carry, so an absent tag describes that object rather than OpenStreetMap, and no value here can steer which object is matched. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | The closest matching OSM object at the given coordinates. |
| attribution | Yes | Required data attribution. |
| tagSelectionCaveat | No | Standing caveat: tag-based selection lives on the Overpass tools (openstreetmap_query_nearby, openstreetmap_query_bbox, openstreetmap_query_raw), never here. extratags decorates the returned objects rather than selecting them, so a missing tag is not evidence the tag is missing from OpenStreetMap. Present when extratags was requested. |
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent hints, the description discloses a key behavioral nuance: Nominatim finds the nearest indexed OSM object, which may differ from the address at exact coordinates in dense areas. It also explains that matching is based on proximity/layer, not OSM tags, and that extratags are decorative — adding valuable context not in 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 efficiently structured with a core definition, a critical caveat, zoom guidance, and alternative tool pointers. Every sentence contributes unique value; no filler or redundancy.
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 (6 parameters, output schema present), the description covers caveats, zoom-level usage, extratags behavior, and sibling alternatives. The output schema handles return values, so no further detail is needed. It is fully complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers 100% of parameters, the description adds practical semantics: zoom levels mapped to accuracy (building, street, city) and extratags explained as opportunistic/decorative rather than selective. This goes beyond the schema's basic descriptions.
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 clearly states the tool converts lat/lon to the nearest address/place name via Nominatim/OpenStreetMap and returns the closest matching OSM object. This distinguishes it from siblings like search_places or query_bbox by specifying the reverse-geocoding operation and output.
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?
It explicitly provides usage context with zoom-level guidance (18=building, 10=city) and names alternative tools for tag-based queries: 'To find the objects in an area that carry a given tag, use openstreetmap_query_nearby, openstreetmap_query_bbox, or openstreetmap_query_raw.' This clearly directs when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openstreetmap_search_placesGeocode a place name or addressARead-onlyIdempotentInspect
Convert a place name or address to geographic coordinates and structured place data via Nominatim/OpenStreetMap. Accepts either a free-form query string (e.g., "Space Needle Seattle") or structured address fields (street, city, state, etc.) — the two modes are mutually exclusive. Returns results ordered by Nominatim relevance (importance score). Use countrycodes to restrict results to specific countries. For exhaustive POI lists in an area, use openstreetmap_query_nearby or openstreetmap_query_bbox instead — Nominatim search returns best matches, not all matching objects. Results are matched on name and address relevance, never on an OSM attribute tag: extratags decorates whichever object matched and cannot select one, so a named feature may resolve to a different OSM object than the one carrying the tags you want. To filter or enumerate by tag (surface, sac_scale, ele, access, amenity), use openstreetmap_query_nearby, openstreetmap_query_bbox, or openstreetmap_query_raw.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name (structured query). | |
| layer | No | Filter by data layer. Comma-separated values: address, poi, railway, natural, manmade. Default: no restriction. | |
| limit | No | Maximum results to return. Nominatim may return fewer when additional results do not sufficiently match. Max 40. | |
| query | No | Free-form search string (e.g., "Space Needle Seattle" or "1600 Pennsylvania Ave NW, Washington DC"). Cannot be combined with structured address fields. Keep the query to a POI name plus its city or region. Do not insert a parent institution, campus, or building name between the name and the locality: Nominatim reads commas as an address hierarchy and returns nothing when an intermediate token is not a matching containment level. For example, use "Beinecke Library, New Haven", not "Beinecke Library, Yale University, New Haven". | |
| state | No | State or province (structured query). | |
| county | No | County or district (structured query). | |
| street | No | House number and street name (structured query). Use with city/state/country fields. Cannot be combined with query. | |
| country | No | Country name or ISO 3166-1 alpha-2 code (structured query). | |
| language | No | Preferred language for result names (BCP 47 code or Accept-Language string, e.g., "en", "de", "fr,en"). Defaults to local OSM language. | |
| extratags | No | Include the extra OSM tags the matched object carries — contact and metadata tags (phone, website, opening_hours, wikidata) and physical attribute tags alike (surface, tracktype, sac_scale, ele, access). Opportunistic, not selective: it reports whatever the matched object happens to carry, so an absent tag describes that object rather than OpenStreetMap, and no value here can steer which object is matched. Increases response size. | |
| postalcode | No | Postal or ZIP code (structured query). | |
| featureType | No | Restrict results to a geographic feature type. Automatically implies the address layer. | |
| countrycodes | No | Restrict results to one or more countries. Comma-separated ISO 3166-1 alpha-2 codes (e.g., "us,ca"). Preferred over the structured country field when filtering. | |
| exclude_place_ids | No | OSM refs (N/W/R + id) or Nominatim place_ids to drop from results, forwarded as the exclude_place_ids parameter. Pass the nextExcludeIds value from a prior truncated response to page toward the next-best matches — it emits stable OSM refs when available, which page more reliably than volatile place_ids. When the walk runs out, the call succeeds with zero results and an exhaustion notice rather than failing — treat that as the loop-termination signal. Best-effort progressive retrieval, not a stable cursor — Nominatim ranking can reorder slightly between calls, so already-seen results may shift. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit applied to this request. |
| shown | No | Number of results returned. |
| total | Yes | Number of results returned. |
| notice | No | Guidance for this page, covering two cases: results were capped at limit (truncated is true — keep paging with nextExcludeIds), or an exclude_place_ids paging walk is exhausted and the page came back empty (the query matched, the walk simply ended, so no rewrite is needed). Tell them apart by truncated and the result count, not by this field being present. Absent when a page returns below the limit without being capped. Carries paging guidance only — the tag-selection caveat has its own field so neither message can overwrite the other. |
| results | Yes | Geocoding results, ordered by Nominatim relevance (importance score descending). |
| truncated | No | True if the result count equals the requested limit (Nominatim may have more). |
| attribution | Yes | Required data attribution: Data © OpenStreetMap contributors, ODbL 1.0. |
| effectiveQuery | Yes | The effective query sent to Nominatim — the free-form query string, or a reconstructed string from the provided structured address fields. |
| nextExcludeIds | No | Accumulated exclude tokens (prior excludes plus this page) to pass as exclude_place_ids on the next call, retrieving the next-best matches. Each token is a stable OSM ref (N/W/R + osm_id) when the result carries one, falling back to the Nominatim place_id otherwise. Present only when results were truncated. Nominatim reports no total, so a truncated page is not proof that more matches exist — the following page may come back exhausted (zero results plus a notice). Best-effort: Nominatim ranking is not perfectly stable across calls. |
| tagSelectionCaveat | No | Standing caveat: tag-based selection lives on the Overpass tools (openstreetmap_query_nearby, openstreetmap_query_bbox, openstreetmap_query_raw), never here. extratags decorates the returned objects rather than selecting them, so a missing tag is not evidence the tag is missing from OpenStreetMap. Present on every successful response. |
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds critical behavior: extratags is 'opportunistic, not selective' and can yield mismatched objects; exclude_place_ids is 'best-effort progressive retrieval, not a stable cursor'; results are ordered by Nominatim relevance; and it warns about query hierarchy pitfalls.
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 longer than average but every sentence earns its place: purpose, query modes, ordering, countrycodes, sibling alternatives, extratags caveat, and tag-filtering guidance. It is logically structured with no fluff or redundancy.
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?
With 14 parameters, multiple sibling tools, and an output schema present, the description thoroughly covers the tool's purpose, modes, limitations, and when to delegate to alternatives. It leaves return values to the output schema and focuses on usage context, making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description enriches meaning for key parameters: query modes with examples and pitfalls, extratags' non-selective decoration, and exclude_place_ids paging with exhaustion signal and stable OSM refs vs volatile place_ids. This goes well beyond the schema descriptions.
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 'Convert a place name or address to geographic coordinates and structured place data via Nominatim/OpenStreetMap' with a specific verb, resource, and output. It distinguishes from siblings by explicitly naming openstreetmap_query_nearby/bbox/raw for exhaustive POI lists and tag filtering.
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?
Provides explicit when-to-use vs alternatives: 'For exhaustive POI lists in an area, use openstreetmap_query_nearby or openstreetmap_query_bbox instead' and 'To filter or enumerate by tag (surface, sac_scale, ele, access, amenity), use openstreetmap_query_nearby, openstreetmap_query_bbox, or openstreetmap_query_raw.' Also clarifies mutual exclusivity of free-form vs structured query modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityDmaintenanceProvides forward/reverse geocoding, bounding box extraction, nearby places discovery, batch geocoding, route waypoints, and administrative boundary lookup using OpenStreetMap data.10Apache 2.0
- FlicenseAqualityCmaintenanceEnables querying OpenStreetMap data (buildings, roads, amenities, etc.) via Overpass API and converts them to GeoJSON format for GIS analysis and visualization.86
- Alicense-qualityCmaintenanceEnables geocoding and reverse geocoding from OpenStreetMap data using the free Nominatim API.2MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.