Skip to main content
Glama

openstreetmap-mcp-server

Geocode a place name or address

openstreetmap_search_places
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoCity name (structured query).
layerNoFilter by data layer. Comma-separated values: address, poi, railway, natural, manmade. Default: no restriction.
limitNoMaximum results to return. Nominatim may return fewer when additional results do not sufficiently match. Max 40.
queryNoFree-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".
stateNoState or province (structured query).
countyNoCounty or district (structured query).
streetNoHouse number and street name (structured query). Use with city/state/country fields. Cannot be combined with query.
countryNoCountry name or ISO 3166-1 alpha-2 code (structured query).
languageNoPreferred language for result names (BCP 47 code or Accept-Language string, e.g., "en", "de", "fr,en"). Defaults to local OSM language.
extratagsNoInclude 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.
postalcodeNoPostal or ZIP code (structured query).
featureTypeNoRestrict results to a geographic feature type. Automatically implies the address layer.
countrycodesNoRestrict 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_idsNoOSM 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

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe limit applied to this request.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of results returned.
totalNoNumber of results returned.
noticeNoGuidance 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.
resultsNoGeocoding results, ordered by Nominatim relevance (importance score descending).
truncatedNoTrue if the result count equals the requested limit (Nominatim may have more).
attributionNoRequired data attribution: Data © OpenStreetMap contributors, ODbL 1.0.
effectiveQueryNoThe effective query sent to Nominatim — the free-form query string, or a reconstructed string from the provided structured address fields.
nextExcludeIdsNoAccumulated 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.
tagSelectionCaveatNoStanding 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.

TDQS

A5/5.0
Behavior5/5

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

Discloses numerous behaviors beyond the annotations: results are ordered by Nominatim relevance, extratags is opportunistic and cannot select a different object, exclude_place_ids is a best-effort cursor with potential reordering, and limit may return fewer results. These caveats align with the readOnlyHint/openWorldHint/idempotentHint annotations without 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?

The description is front-loaded with the core purpose, then progressively adds usage modes, alternative routing, and behavioral caveats. While lengthy, every sentence contributes unique value—no redundancy or filler. The structure guides the agent from basic invocation to advanced pitfalls in logical order.

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 tool with 14 parameters and an output schema, the description covers all critical aspects: input modes, country/feature filtering, language handling, the extratags limitation, and the pagination mechanism. It also positions itself against sibling tools, ensuring the agent has everything needed to call it correctly without ambiguity. The output schema handles return details, so its absence in the description is acceptable.

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?

Despite 100% schema coverage, the description adds substantial meaning that the schema lacks: detailed guidance on query formatting (comma hierarchy handling), explanation that extratags reflects the matched object's own tags and cannot steer selection, and the paging semantics of exclude_place_ids including stable OSM refs and exhaustion signaling. This goes well beyond the parameter 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 a place name or address to geographic coordinates and structured place data via Nominatim/OpenStreetMap. It distinguishes itself from siblings by explicitly noting it returns best matches, not exhaustive lists, and points to alternatives for that purpose. The verb and resource are specific and unambiguous.

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 guidance is provided on when to use this tool versus alternatives: 'For exhaustive POI lists in an area, use openstreetmap_query_nearby or openstreetmap_query_bbox instead' and for tag filtering it lists query_nearby/bbox/raw. It also explains the two mutually exclusive input modes (free-form query vs structured fields) and warns against inserting non-matching hierarchy tokens like 'Beinecke Library, Yale University, New Haven'.

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.