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 |
|---|---|---|
| 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. |
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 that results are ordered by relevance and that Nominatim returns best matches, not all. It also mentions that extratags increases response size. No contradictions.
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 (3 sentences) and front-loads the core purpose. Every sentence contributes additional context 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 presence of a full output schema and annotations, the description covers purpose, usage, parameter nuances, and alternatives. No gaps for an agent to invoke the tool correctly.
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 provides 100% parameter descriptions. The description adds value by explaining mutual exclusivity of query and structured fields, the behavior of the limit parameter (may return fewer), and the relationship between countrycodes and country field. Minor deduction because schema already covers details.
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 the tool converts place names/addresses to coordinates and structured data using Nominatim/OSM. It distinguishes from siblings by noting that for exhaustive POI lists, one should use openstreetmap_query_nearby or openstreetmap_query_bbox instead.
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 explains when to use (geocoding) and when not (for exhaustive lists, use alternatives). Also clarifies the two mutually exclusive input modes (query vs structured fields) and suggests using countrycodes for filtering.
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). | |
| 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 or add more specific tags to narrow the result set. |
| 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, idempotentHint. Description adds value by clarifying that limit is applied after query (truncation), that extratags flag does not apply here, and that every feature includes full OSM tag set. No contradictions.
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, each purposeful: purpose, usage guidance, parameter constraints, output characteristics and sibling reference. No fluff, front-loaded with key 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?
With 10 parameters, 100% schema coverage, output schema present, and full annotations, description provides additional context: parameter exclusivity, truncation behavior, output details, and relevant sibling tool. Covers all necessary guidance for effective 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%, so baseline 3. Description adds meaning by explaining that exactly one of amenity or tag_key/tag_value must be provided, and gives examples (amenity for common POIs, tag_key/tag_value for other categories). Also clarifies element_types and timeout_seconds usage beyond schema descriptions.
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?
Clear verb ('Find') and resource ('OSM features within a bounding box'). Explicitly distinguishes from sibling tools like openstreetmap_query_nearby by stating it's for area surveys not 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 ('area surveys where you want everything in a region') and when not to ('for proximity searches... use openstreetmap_query_nearby instead'), with specific alternative named.
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. | |
| 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 or add more specific tags to narrow the result set. |
| 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: results sorted nearest-first by distance_meters, each result includes full OSM tag set, limit applied after query truncation, and radius recommendation for urban areas. No contradictions.
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 concise yet comprehensive. Front-loads purpose and usage, then covers parameters efficiently. Every sentence adds value; no redundant or vague statements.
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, 2 required, 100% schema coverage, output schema present), the description is fully complete. It addresses constraints, recommendations, and behavioral nuances without requiring additional information.
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 description coverage is 100%, but the description adds extra context beyond schema: e.g., limit truncation behavior, radius density recommendation, element type coverage (nodes=POIs, ways=buildings/areas), and mutual exclusivity of amenity and tag_key/tag_value.
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: 'Find OSM features within a radius around a geographic point via the Overpass API.' It uses specific verb 'Find' and resource 'OSM features', and distinguishes itself from siblings by being 'The primary tool for "what's near X?" 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 ('what's near X?'), provides guidance on parameter choices (amenity vs tag_key/tag_value, exactly one required), and explains element types. Also clarifies that extratags flag is not needed here, distinguishing from Nominatim-based tools.
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!