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.8/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: geocode for place names, lookup for OSM IDs, query_bbox and query_nearby for spatial searches (box vs radius), query_raw for arbitrary Overpass QL, and reverse for coordinates to address. No overlap in functionality.
All tool names follow the consistent pattern 'openstreetmap_<verb>', with descriptive verbs like 'geocode', 'lookup', 'query_bbox', 'query_nearby', 'query_raw', 'reverse'. The naming is uniform and predictable.
With 6 tools, the server is well-scoped for an OSM query interface. It covers geocoding, reverse geocoding, spatial queries (box and radius), raw querying, and lookup by ID — no redundancy or unnecessary tools.
The tool set comprehensively covers common OSM query needs: geocoding, reverse geocoding, bounding box and nearby searches, raw Overpass QL, and OSM ID lookup. There are no obvious gaps for a read-only query server.
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. | |
| 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Number of results returned. |
| results | Yes | Geocoding results, ordered by Nominatim relevance (importance score descending). |
| 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?
Adds behavioral context beyond annotations: results ordered by Nominatim importance, limit may return fewer if insufficient match, extratags increases response size, and modes are mutually exclusive. 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?
Concise description front-loaded with main purpose. Each sentence serves a purpose without redundancy. Efficiently covers key points in few sentences.
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 13 parameters with full schema coverage and existing output schema, description covers key behavioral aspects: return ordering, limit behavior, mode exclusivity, country restriction. Cross-references sibling tools for context 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?
Schema coverage is 100%, and description adds critical semantics: mutual exclusivity of query and structured fields, preference for countrycodes over country for filtering, and default language behavior.
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?
Description clearly states it converts a place name or address to coordinates and structured place data via Nominatim/OpenStreetMap. It distinguishes between free-form query and structured address fields and explicitly names sibling tools for exhaustive POI searches.
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 (for geocoding) and when not to (use openstreetmap_query_nearby or openstreetmap_query_bbox for exhaustive POI lists). Also provides guidance on using countrycodes to restrict results.
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. 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). | |
| 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 |
|---|---|---|
| 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 or add more specific tags to narrow the result set. |
| attribution | Yes | Required data attribution: Data © OpenStreetMap contributors, ODbL 1.0. |
| total_found | Yes | Total features returned by Overpass before limit truncation. |
| 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 context about using the Overpass API and clarifies that the limit is 'applied after the Overpass query' with truncation behavior. No contradictions found.
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 a single focused paragraph, front-loaded with the purpose, then usage context, then parameter logic, and ends with a sibling alternative. Every sentence adds value without redundancy.
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 10 parameters and the presence of an output schema, the description covers all critical usage aspects: bounding box coordinates, element types, limit behavior, timeout adjustment, and the amenity vs tag_key/tag_value distinction. No gaps remain for effective selection and use.
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%, providing a baseline of 3. The description adds the crucial constraint that 'Exactly one of amenity or tag_key/tag_value must be provided', which is not enforced in the schema. It also explains the difference between amenity as a shortcut and tag_key/tag_value for other categories.
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 starts with a specific verb ('Find') and resource ('OSM features within a bounding box'), and distinguishes itself from the sibling tool openstreetmap_query_nearby by mentioning 'area surveys' vs 'proximity searches'.
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 this tool ('area surveys where you want everything in a region') and when not to use it ('For proximity searches centered on a point, use openstreetmap_query_nearby instead'). Also explains the mutual exclusivity of 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). Note: results are not sorted by distance — the Overpass API returns them in OSM element ID order.
| 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. | |
| 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 |
|---|---|---|
| elements | Yes | Matching OSM features, up to the limit. |
| truncated | Yes | True if results were cut at the limit. Reduce radius or add more specific tags to narrow the result set. |
| attribution | Yes | Required data attribution: Data © OpenStreetMap contributors, ODbL 1.0. |
| total_found | Yes | Total features returned by Overpass before limit truncation. |
| 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 indicate read-only, idempotent, and open-world behavior. The description adds valuable behavioral context: results are not sorted by distance, limit is applied after query truncation, and element types cover different features. 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?
The description is a single cohesive paragraph with no wasted words. Every sentence provides essential information, and it is appropriately sized for the complexity of the tool.
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 (9 parameters, output schema exists), the description covers the primary use case, parameter dependencies, behavior traits, and practical considerations (e.g., radius limits for dense areas). The output schema handles return value details.
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?
The schema covers all 9 parameters with descriptions (100% coverage). The description adds extra meaning beyond schema: exclusivity of amenity and tag_key/tag_value, use cases for common tag combinations, and hints for radius selection in dense areas.
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 finds OSM features within a radius via the Overpass API and identifies it as the primary tool for 'what's near X?' queries. It distinguishes itself from sibling tools by specifying the spatial proximity use case.
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 indicates when to use this tool (spatial proximity) and provides guidance on parameter selection (amenity vs. tag_key/tag_value, exclusivity). It mentions result ordering but could further clarify when to prefer alternative tools like bounding box queries for rectangular areas.
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 |
|---|---|---|
| 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. |
| 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, idempotentHint. The description adds important behavioral context: the query must include [out:json], timeout precedence rules, and that the server sets endpoint/User-Agent. This goes beyond annotations but does not contradict them.
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 (few sentences) and well-structured: it states purpose, lists when to use, gives example, advises validation, and directs to alternatives. Every sentence serves a purpose; no waste.
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 executes arbitrary queries, the description covers all essential aspects: purpose, usage criteria, parameter details (with example and precedence), and sibling alternatives. With an output schema present, return values need not be explained. Complete and self-contained.
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 schema itself documents both parameters well. The description adds value by providing a concrete example and clarifying the timeout precedence (the query string directive takes precedence over the parameter). This supplement is helpful but not transformative.
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 executes raw Overpass QL queries for advanced spatial queries not covered by convenience tools. It lists specific use cases (multi-type, union, relation membership, historical) and explicitly distinguishes from sibling tools by naming openstreetmap_query_nearby and openstreetmap_query_bbox as alternatives for simple 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 gives explicit when-to-use guidance (advanced queries) and when-not-to-use (simple queries, recommending alternatives). It also provides validation advice (use overpass-turbo.eu) and format requirements ([out:json]).
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!