F
licenseNot graded
qualityD
maintenanceConverts Ghana Post GPS addresses into detailed location information including coordinates.
1
-
DaedalMap Reverse Geocoding (coordinates to loc_id)
Server Details
Convert WGS84 coordinates to the latest available administrative loc_id chain.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- xyver/daedal-map
- GitHub Stars
- 2
- Server Listing
- daedal-map
Available Tools
4 toolsget_catalogGet CatalogARead-onlyInspect
Free discovery. Returns the list of live agent-ready data packs available on DaedalMap.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the readOnlyHint annotation by specifying the catalog contains live, agent-ready data packs and that it is a free discovery operation. It does not contradict the annotation and provides some added behavioral context, though it omits details like rate limits or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that are front-loaded ('Free discovery' immediately conveys the tool's nature) and no wasted words. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and only a readOnlyHint annotation, the description is nearly complete for its simplicity. It explains what is returned and the platform, though it could potentially clarify the format of the data packs or intended use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema description coverage is 100%. The description does not need to explain parameter semantics, and the baseline for 0-parameter tools is 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of live agent-ready data packs on DaedalMap, with the specific verb 'Returns' and resource. This distinguishes it from sibling tools like get_pack (which presumably fetches a specific pack) and resolve_point (which likely resolves a point).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Free discovery' implies the tool is for discovering available data packs, but it does not explicitly state when to use this tool over alternatives or provide exclusions. It offers implied usage context but lacks explicit guidance or mention of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_packGet PackARead-onlyInspect
Free discovery. Returns detailed metadata, coverage, freshness, preferred canonical tool guidance, and first-query examples for one pack. Call this before querying a new pack so you can see time shape, coverage limits, and the paste-ready first query.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pack_id | Yes | Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change. |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe, non-mutating nature is established. The description adds context about what kind of information is returned ('coverage, freshness, preferred canonical tool guidance, first-query examples') but does not go further into rate limits, errors, or other behavioral traits. With annotations covering the core safety profile, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are used with no wasted words. The key behavioral instruction ('free discovery') is front-loaded, followed by the return contents and the when-to-use guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description fully covers what the agent gets back and when to call it. It names the return categories and the intended workflow step, which is sufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: pack_id is described as 'Pack identifier from get_catalog.' The description does not add new parameter-level meaning beyond implying the pack_id selects a single pack. Since the schema carries the full parameter documentation, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Returns') and a clear resource ('detailed metadata, coverage, freshness, preferred canonical tool guidance, and first-query examples for one pack'). It distinguishes this tool from get_catalog by emphasizing 'one pack' rather than the overall catalog. The purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this tool before querying a new pack, giving a clear context of use. It does not explicitly state when not to use it or name alternative tools, but the guidance is strong enough to direct an agent's behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tool_helpGet Tool HelpARead-onlyInspect
Free blind-caller guidance for one tool visible on this MCP facade. Returns when to use it, what it refuses, a working example, effective access limits, important outputs, provenance fields, recommended next calls, and the shared natural-language-to-strict-JSON interaction contract. Use tools/list to discover names, then call this before an unfamiliar tool.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | Yes | Exact tool name from tools/list. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals safety, and the description reinforces it by saying the tool 'Returns' guidance rather than mutating anything. It adds useful behavioral context about output contents—refusals, effective limits, provenance fields, recommended next calls—without contradicting the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense, front-loaded sentences with zero fluff. The first sentence immediately states what the tool does and enumerates its rich output; the second provides the usage pattern. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with no output schema, the description enumerates all major return categories (usage guidance, refusals, example, access limits, outputs, provenance, next calls, interaction contract), making the tool's behavior transparent. It also covers prerequisites and workflow, so an agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single tool_name parameter with 'Exact tool name from tools/list.' The description adds the practical discovery workflow (use tools/list) but does not otherwise enhance parameter semantics beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Free blind-caller guidance for one tool visible on this MCP facade.' It lists concrete outputs (when to use, refusals, example, limits, outputs, provenance, next calls), clearly distinguishing this help tool from sibling tools like get_catalog or resolve_point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs the agent: 'Use tools/list to discover names, then call this before an unfamiliar tool.' This gives a crisp when-to-use workflow and an implied when-not-to-use (familiar tools). It also names the prerequisite discovery tool (tools/list) as an alternative first step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_pointResolve Point to loc_idARead-onlyInspect
Compact reverse geocoding. Converts one WGS84 point, or a bounded point list, into the latest-available administrative loc_id chain. Each chain row is intentionally small: loc_id, name, admin level, and vintage when available. This tool does not return polygons, hierarchy analysis, references, overlap percentages, lifecycle, provenance, or release-conversion detail. Pass the returned stack loc_ids to loc_id_info for details; use get_geometry for shapes and compare_geographies for relationships. Small exploratory calls may omit scope and resolve through the deepest served tier. Batches above the 25-point preview must declare exactly one country_scope and one target_admin_level; split multi-country input into one call per country. Cross-country admin-0/admin-1 batches may instead use bulk_preset. Anonymous callers pay above 25, while verified accounts receive included bulk throughput through 10,000 points. Current catalog: The same geography tools work worldwide across a cataloged baseline of 252 geographic entities, reaching up to Admin 2. Where additional country releases are available, the same calls automatically return deeper administrative tiers or maintained reference families. Additional detail is currently available for Australia, Brazil, Canada, France, Germany, Mexico, United Kingdom, United States.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude in WGS84 decimal degrees. | |
| lon | No | Longitude in WGS84 decimal degrees. | |
| points | No | Points to resolve. Up to 25 may be exploratory. Above 25, country_scope and target_admin_level are required. Anonymous callers receive a payment challenge; verified accounts have included throughput through 10,000 points. | |
| batch_id | No | Optional caller-supplied batch id echoed in the result. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| bulk_preset | No | Cross-country fast path that fixes the result level to admin_0 or admin_1. Use instead of country_scope; target_admin_level may be omitted. | |
| country_hint | No | Alias for country_scope for clients that already use hint terminology. | |
| country_scope | No | ISO3/admin_0 loc_id scope such as USA or CAN. Optional for up to 100 exploratory points and required for larger batches; every point must belong to this one country. | |
| target_admin_level | No | Stopping level such as admin_0 through admin_5. Optional for up to 100 exploratory points and required for larger batches. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint annotation: it lists deliberately excluded fields, documents throughput and payment behavior for anonymous vs verified callers, explains the 25-point preview threshold, and spells out the current catalog coverage. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with purpose and behavior before operating constraints. The catalog/coverage paragraph is somewhat expansive, but it conveys useful expectations about geography depth, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description names the return chain fields and what is intentionally absent, and it gives enough constraints to call the tool correctly. The main gap is an internal inconsistency between the 25-point and 100-point exploratory thresholds, which the description does not resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantic guidance: what happens when scope is omitted, the exact batch-size trigger for requiring country_scope and target_admin_level, and the bulk_preset alternative. It does not add much for batch_id/request_id, but those are already self-explanatory in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line names a specific operation and resource: 'Converts one WGS84 point, or a bounded point list, into the latest-available administrative loc_id chain.' This is far more precise than the title and clearly separates resolve_point from the sibling catalog/help tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says what to do with the results ('Pass the returned stack loc_ids to loc_id_info for details; use get_geometry for shapes and compare_geographies for relationships') and when to prefer bulk_preset over country_scope. It also directs users to split multi-country input into one call per country.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- Changed
resolve_point2 fields changed- changed
Input schema / properties / country_scope / descriptionPrevious value: -"ISO3/admin_0 loc_id scope such as USA or CAN. Optional for up to 25 exploratory points and required for larger batches; every point must belong to this one country."New value: +"ISO3/admin_0 loc_id scope such as USA or CAN. Optional for up to 100 exploratory points and required for larger batches; every point must belong to this one country." - changed
Input schema / properties / target_admin_level / descriptionPrevious value: -"Stopping level such as admin_0 through admin_5. Optional for up to 25 exploratory points and required for larger batches."New value: +"Stopping level such as admin_0 through admin_5. Optional for up to 100 exploratory points and required for larger batches."
1 tool update
- Changed
get_pack1 field changed- changed
Input schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."New value: +"Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change."
1 tool update
- Changed
resolve_point4 fields changed- added
Input schema / properties / bulk_presetAdded value: +{ + "description": "Cross-country fast path that fixes the result level to admin_0 or admin_1. Use instead of country_scope; target_admin_level may be omitted.", + "enum": [ + "global_admin_0", + "global_admin_1" + ], + "type": "string" +} - changed
Input schema / properties / country_scope / descriptionPrevious value: -"Optional ISO3/admin_0 loc_id scope such as USA or CAN. Use only when every point in the request should be resolved inside that one country; this lets the runtime skip global country detection and use one country geometry bank."New value: +"ISO3/admin_0 loc_id scope such as USA or CAN. Optional for up to 25 exploratory points and required for larger batches; every point must belong to this one country." - changed
Input schema / properties / points / descriptionPrevious value: -"Points to resolve. Hosted default free preview is 25 points; larger valid batches return a payment-required quote instead of executing for free."New value: +"Points to resolve. Up to 25 may be exploratory. Above 25, country_scope and target_admin_level are required. Anonymous callers receive a payment challenge; verified accounts have included throughput through 10,000 points." - changed
Input schema / properties / target_admin_level / descriptionPrevious value: -"Optional stopping level such as admin_0 through admin_5. Omit for the normal complete chain through the deepest currently served tier."New value: +"Stopping level such as admin_0 through admin_5. Optional for up to 25 exploratory points and required for larger batches."
1 tool update
- Added
get_tool_help
1 tool update
- Changed
resolve_point2 fields changed- removed
Input schema / properties / include_geometryRemoved value: -{ - "description": "When true, include geometry in resolver internals where available. Default false to keep responses small.", - "type": "boolean" -} - changed
Input schema / properties / target_admin_level / descriptionPrevious value: -"Requested administrative level such as admin_0, admin_1, admin_2, admin_3, admin_4, or admin_5. Default admin_2. Use deepest/all only when the caller explicitly needs the deepest supported local geometry."New value: +"Optional stopping level such as admin_0 through admin_5. Omit for the normal complete chain through the deepest currently served tier."
1 tool update
- Changed
resolve_point5 fields changed- removed
Input schema / properties / countryRemoved value: -{ - "description": "Alias for parent_loc_id/country_scope when the scope is an ISO3 country code.", - "type": "string" -} - changed
Input schema / properties / country_hint / descriptionPrevious value: -"Alias for parent_loc_id/iso3. Use one country per paid/trusted bulk batch."New value: +"Alias for country_scope for clients that already use hint terminology." - changed
Input schema / properties / country_scope / descriptionPrevious value: -"Alias for parent_loc_id when the scope is an admin_0/country loc_id."New value: +"Optional ISO3/admin_0 loc_id scope such as USA or CAN. Use only when every point in the request should be resolved inside that one country; this lets the runtime skip global country detection and use one country geometry bank." - removed
Input schema / properties / iso3Removed value: -{ - "description": "Alias for parent_loc_id/country_scope when the scope is an ISO3 country code.", - "type": "string" -} - removed
Input schema / properties / parent_loc_idRemoved value: -{ - "description": "Optional country scope such as USA, CAN, or IND. Required for paid/trusted bulk point batches over the free preview limit. Bulk should use one country and one target_admin_level per call.", - "type": "string" -}
1 tool update
- Changed
resolve_point5 fields changed- added
Input schema / properties / countryAdded value: +{ + "description": "Alias for parent_loc_id/country_scope when the scope is an ISO3 country code.", + "type": "string" +} - added
Input schema / properties / country_hintAdded value: +{ + "description": "Alias for parent_loc_id/iso3. Use one country per paid/trusted bulk batch.", + "type": "string" +} - added
Input schema / properties / country_scopeAdded value: +{ + "description": "Alias for parent_loc_id when the scope is an admin_0/country loc_id.", + "type": "string" +} - added
Input schema / properties / iso3Added value: +{ + "description": "Alias for parent_loc_id/country_scope when the scope is an ISO3 country code.", + "type": "string" +} - added
Input schema / properties / parent_loc_idAdded value: +{ + "description": "Optional country scope such as USA, CAN, or IND. Required for paid/trusted bulk point batches over the free preview limit. Bulk should use one country and one target_admin_level per call.", + "type": "string" +}
1 tool update
- Changed
resolve_point2 fields changed- changed
Input schema / properties / points / descriptionPrevious value: -"Points to resolve. Hosted default maximum is 25 points per call."New value: +"Points to resolve. Hosted default free preview is 25 points; larger valid batches return a payment-required quote instead of executing for free." - added
Input schema / properties / target_admin_levelAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ], + "description": "Requested administrative level such as admin_0, admin_1, admin_2, admin_3, admin_4, or admin_5. Default admin_2. Use deepest/all only when the caller explicitly needs the deepest supported local geometry." +}
1 tool update
- Changed
resolve_point5 fields changed- added
Input schema / anyOfAdded value: +[ + { + "required": [ + "lat", + "lon" + ] + }, + { + "required": [ + "points" + ] + } +] - added
Input schema / properties / batch_idAdded value: +{ + "description": "Optional caller-supplied batch id echoed in the result.", + "type": "string" +} - added
Input schema / properties / include_geometryAdded value: +{ + "description": "When true, include geometry in resolver internals where available. Default false to keep responses small.", + "type": "boolean" +} - added
Input schema / properties / pointsAdded value: +{ + "description": "Points to resolve. Hosted default maximum is 25 points per call.", + "items": { + "additionalProperties": false, + "properties": { + "id": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "string" + } + ], + "description": "Optional caller point identifier echoed in the result." + }, + "lat": { + "description": "Latitude in WGS84 decimal degrees.", + "maximum": 90, + "minimum": -90, + "type": "number" + }, + "lon": { + "description": "Longitude in WGS84 decimal degrees.", + "maximum": 180, + "minimum": -180, + "type": "number" + }, + "row_index": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "string" + } + ], + "description": "Optional caller row identifier echoed in the result." + } + }, + "required": [ + "lat", + "lon" + ], + "type": "object" + }, + "minItems": 1, + "type": "array" +} - removed
Input schema / requiredRemoved value: -[ - "lat", - "lon" -]
3 tool updates
- First observed
get_catalog - First observed
get_pack - First observed
resolve_point
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Resolve coordinates and geographic identifiers to loc_id, crosswalks, boundaries, and exports.
Resolve coordinates against delivery and coverage polygons (geofences).
Worldwide place search with coordinates (Open-Meteo) — paid per call (x402/credits), 1 tools
Turn a GPS coordinate into a shareable short link and QR code, as your own signed-in account.
Related MCP Servers
- AlicenseAqualityDmaintenanceTurn GPS coordinates into place name, category, and live opening hours via OpenStreetMap. Works in Claude, Hermes Agent, OpenClaw, and any MCP client.11MIT
- AlicenseBqualityDmaintenanceProvides geocoding, reverse geocoding, location lookup, and DigiPin processing capabilities using the QuantaRoute API, enabling AI assistants to convert addresses to coordinates and retrieve administrative boundaries.1355MIT
- AlicenseAqualityCmaintenanceProvides global geocoding capabilities to convert city names and addresses into latitude/longitude coordinates using the free OpenStreetMap Nominatim API.15MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.5/5.0
Disambiguation5/5
Each tool has a clear, distinct purpose: get_catalog lists available packs, get_pack provides metadata for a specific pack, and resolve_point performs reverse geocoding. There is no overlap or ambiguity between them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with underscores (get_catalog, get_pack, resolve_point). The naming style is uniform and predictable.
Tool Count5/5
With only 3 tools, the server is tightly scoped for its stated purpose of reverse geocoding with discovery support. This is within the ideal range and avoids unnecessary bloat.
Completeness5/5
The server covers the full workflow needed for its purpose: discovering available packs, inspecting pack details, and resolving coordinates to loc_id chains. The referenced external tools (e.g., loc_id_info, get_geometry) are clearly extensions beyond this server's scope.