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
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Tool Definition Quality
Average 4.6/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: geocode resolves addresses to coordinates, reverse does opposite, lookup retrieves by ID, query_bbox and query_nearby handle spatial queries by rectangle and radius respectively, and query_raw enables arbitrary Overpass queries. No two tools overlap in functionality.
All tools follow the consistent pattern 'openstreetmap_<verb>' with variations only for query subtypes (_bbox, _nearby, _raw). Verbs are descriptive and the prefix ensures namespace clarity.
With 6 tools, the server covers the essential OSM operations (geocoding, lookup, spatial queries) without unnecessary bloat. Each tool earns its place and the count feels natural for the domain.
The tool set covers forward and reverse geocoding, ID-based lookup, bounding box and proximity queries, and a raw query escape hatch. This is sufficient for most read-only OSM workflows; no obvious gaps.
Available Tools
6 toolsopenstreetmap_geocodeGeocode 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.
| 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 extra OSM tags when available (e.g., phone, website, opening_hours, wikidata). 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 | 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. Best-effort progressive retrieval, not a stable cursor — Nominatim ranking can reorder slightly between calls, so already-seen results may shift. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit applied to this request. |
| shown | No | Number of results returned. |
| total | Yes | Number of results returned. |
| 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 place_ids (prior excludes plus this page) to pass as exclude_place_ids on the next call, retrieving the next-best matches. Present only when results were truncated. Best-effort: Nominatim ranking is not perfectly stable across calls. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, indicating a safe, read-only operation. The description adds valuable behavioral context: results are ordered by Nominatim relevance, the limit parameter may return fewer results, and exclude_place_ids provides best-effort paging with possible reordering. This goes beyond the annotations to disclose nuanced behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. It states the primary purpose in the first sentence, then covers modes, ordering, country restrictions, sibling differentiation, and a critical usage tip—all in 6 sentences with no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, 0 required, 100% schema coverage, output schema exists, and 5 sibling tools), the description is complete. It covers input modes, result behavior, parameter interactions, and when to choose alternatives. The presence of an output schema means return values need not be described, further justifying the completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. However, the description adds extra practical guidance: the query parameter warning about comma-separated address hierarchies, the extratags parameter increasing response size, and the exclude_place_ids explanation for progressive retrieval. These details help the agent avoid common errors and understand trade-offs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Convert a place name or address to geographic coordinates and structured place data via Nominatim/OpenStreetMap.' It specifies the verb (convert), resource (place name/address), and output (coordinates and structured data). It distinguishes from siblings by noting that this tool returns best matches, not exhaustive lists, directing users to other tools for exhaustive queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool versus alternatives: '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.' It also explains the two mutually exclusive modes (free-form query vs structured fields) and advises on query formatting to avoid common pitfalls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openstreetmap_lookupLook 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.
| Name | Required | Description | Default |
|---|---|---|---|
| osm_ids | Yes | One or more OSM IDs, each prefixed with N (node), W (way), or R (relation). E.g., "N240109189", ["W50637691", "R146656"]. Up to 50 IDs per call. | |
| language | No | Preferred language for names (BCP 47 code). | |
| extratags | No | Include extra OSM tags (phone, website, wikidata, etc.). |
Output 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld hints. The description adds practical constraints (up to 50 IDs per call, ID prefix format) 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver complete information without redundancy, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema (mentioned), the description covers input format, limits, and usage scenario, leaving no gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds value by explaining the efficiency rationale and providing concrete examples of ID prefixes, which aids correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches address details for known OSM objects by ID, distinguishing it from siblings like geocoding or spatial queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after query_nearby/bbox) and why it's more efficient than a geocoding round trip, providing clear usage context.
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 geocode/reverse/lookup) does not apply here. For proximity searches centered on a point, use openstreetmap_query_nearby instead.
| Name | Required | Description | Default |
|---|---|---|---|
| east | Yes | Eastern boundary longitude (maximum longitude). | |
| west | Yes | Western boundary longitude (minimum longitude). | |
| 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. Ways cover most buildings and areas; nodes cover most standalone POIs. Add "relation" for complex structures. | |
| timeout_seconds | No | Overpass query timeout in seconds. Increase for large bounding boxes or dense areas. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no features were found — e.g., try a different bounding box or tag. 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 | Yes | OSM data freshness timestamp from the Overpass response. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral details: every feature includes full OSM tag set, extratags not applicable, offset caching with deterministic re-paging, and limit applied after query (truncation). Consistent 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with no wasted words. Each sentence adds distinct value: purpose, usage guidance, parameter constraints, behavioral notes. Well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, 4 required, output schema exists), the description covers all essential aspects: purpose, when to use, parameter relationships, caching, limit truncation, alternative tool. Output schema handles return format, so description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds mutual exclusivity of amenity and tag_key/tag_value, caching behavior for offset, and truncation semantics for limit. This goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds OSM features within a bounding box via Overpass API, distinguishes from proximity searches, and explains usage for area surveys. It specifies the required parameters (amenity or tag_key/tag_value) and the output includes full OSM tag sets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (area surveys) and when not (proximity searches), directly names the alternative tool (openstreetmap_query_nearby). Provides guidance on choosing between amenity and tag_key/tag_value.
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 geocode/reverse/lookup tools.
| 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. Ways cover most buildings and areas; nodes cover most standalone POIs. Add "relation" for complex structures like large campuses. | |
| 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
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no features were found — e.g., try a larger radius or different tag. 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 | Yes | OSM data freshness timestamp from the Overpass response. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld. Description adds: uses Overpass API, returns full OSM tag set, sorted by distance, includes element types, caching for offset paging (~10 minutes), and limit truncation. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is 5 sentences, well-structured, front-loaded with purpose. Includes necessary details without being verbose. Slightly longer than minimal, but each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, 2 required, and output schema exists, the description covers usage patterns, exclusivity, sorting, distance limits, element types, timeout, and paging cache. No gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions. Description adds value by clarifying exclusivity of amenity vs tag_key/tag_value, explaining element_types (nodes for POIs, ways for buildings/areas), and recommending radius_meters under 5000m for dense urban queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find OSM features within a radius around a geographic point'. It specifies the Overpass API, the 'what's near X?' use case, and distinguishes from siblings by noting that 'extratags flag is not needed here — it applies only to the Nominatim-backed geocode/reverse/lookup tools.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use 'amenity' for common POIs, 'tag_key/tag_value' for others, exactly one must be provided. Advises not to use 'extratags' here. Does not explicitly state when to use sibling tools like query_bbox or query_raw, but sibling names and context help infer.
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;" 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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;" | |
| timeout_seconds | No | Query timeout in seconds. The [timeout:N] directive in the query string takes precedence if present. Max 180s. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no elements were returned — e.g., check query syntax or broaden the filter. Absent when results were returned. |
| elements | Yes | Raw Overpass API response elements. Structure varies by query type — nodes have lat/lon, ways have nodes[], relations have members[]. |
| attribution | Yes | Required data attribution: Data © OpenStreetMap contributors, ODbL 1.0. |
| data_timestamp | No | OSM data freshness timestamp from the Overpass response. Absent if not included in the response. |
| effectiveQuery | Yes | The Overpass QL string as sent to the API (after any timeout injection). |
| total_elements | Yes | Number of elements returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context: the requirement for [out:json], timeout precedence, and the maximum timeout of 180s. This adds value beyond annotations, though it could mention the database impact (none, as read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, each sentence adding value. No redundant or vague statements. The structure is logical and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers purpose, usage boundaries, constraints, example, timeout behavior, and validation. It is complete enough for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions for both parameters are detailed. The description doesn't add significant new meaning beyond the schema; it repeats the query format requirement and timeout precedence. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'execute' and resource 'raw Overpass QL query', and distinguishes it from convenience tools by specifying it's for advanced queries. It lists concrete use cases like multi-type and union queries, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (advanced, multi-type, etc.) and when not to use (simple queries, directing to sibling tools openstreetmap_query_nearby or openstreetmap_query_bbox). Also provides a validation suggestion via overpass-turbo.eu, offering complete usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openstreetmap_reverseReverse 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).
| 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 extra OSM tags when available (phone, website, opening_hours, wikidata, etc.). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | The closest matching OSM object at the given coordinates. |
| attribution | Yes | Required data attribution. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, and idempotent behavior. The description adds valuable behavioral context beyond these: it explains the tool's behavior (returns nearest indexed OSM object, potential inaccuracy in dense areas) and the effect of the zoom parameter on accuracy. There is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three sentences with no wasted words. The first sentence defines the core purpose, the second adds a critical behavioral note, and the third provides actionable guidance on the zoom parameter. It is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 exists), the description covers all essential aspects: the main functionality, the key behavioral nuance about nearest indexed object, and parameter tuning for accuracy. The presence of an output schema reduces the need to describe return values. The description is complete for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides descriptions for all 6 parameters (100% coverage). The description adds specific guidance on the zoom parameter, explaining the mapping from zoom values to geographical detail (e.g., zoom=18 for building-level), which goes beyond the schema's generic description. Other parameters (layer, language, extratags) are not mentioned, but the schema already documents them adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: converting lat/lon coordinates to the nearest address or place name via Nominatim/OpenStreetMap. It uses a specific verb ('Convert') and resource ('latitude/longitude coordinates to... address or place name'), effectively distinguishing it from sibling tools like openstreetmap_geocode (forward geocoding) and openstreetmap_lookup (OSM object lookup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when and how to use the tool: it notes that Nominatim returns the nearest indexed OSM object, which may differ from the exact coordinate in dense areas, and it recommends zoom=18 for building-level accuracy. This gives context for parameter selection and expectation setting. However, it does not explicitly mention when not to use this tool or suggest alternatives among the sibling tools.
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!