Skip to main content
Glama
astroway-mcp

astroway-mcp

Official
by astroway

Nearest place to coordinates

astroway_geo_reverse
Read-onlyIdempotent

Reverse-geocode coordinates to the nearest populated place and local timezone, with antimeridian, polar, and open-water handling that reports nautical time and distance.

Instructions

The populated place nearest to a point, by great-circle distance over the same list as /geo/search, and the IANA zone of the point itself (which near a border can differ from the place's). Works across the antimeridian and at the poles. At sea timezone is the nautical hour band (Etc/GMT+2, whose sign is inverted by POSIX convention) and nautical is true; place.distanceKm says how far the nearest place is, so a point in open water is not mistaken for a town. featureCode PPLX marks a section of a city rather than a city.

[Group: Astro-Geography] [Endpoint: GET /v1/geo/reverse] [Required: lat, lon] [Cost: 5 credits (Tier ½)]

Input Schema

NameRequiredDescriptionDefault
latYesLatitude in decimal degrees, north positive.
lonYesLongitude in decimal degrees, east positive.
langNoLanguage for the place, region and country names.

Output Schema

NameRequiredDescriptionDefault
placeNo
datasetNo
latitudeNo
nauticalNo
timezoneNo
longitudeNo
attributionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.1

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive semantics, and the description goes well beyond them: antimeridian and polar handling, the nautical Etc/GMT sign inversion at sea, the `nautical` flag, and the PPLX caveat that a feature may be a city section rather than a city. These are exactly the non-obvious behaviors an agent needs to interpret results correctly.

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 core purpose is front-loaded in the first clause, and each subsequent clause adds a distinct edge-case fact rather than filler. It is dense and slightly run-on, but no sentence is wasted.

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 3-parameter read-only lookup with an output schema, the description covers the remaining ambiguity: what the nearest-place result means, how distance is reported, and how sea and border cases are represented. Nothing an agent needs to call or interpret it is missing.

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%, with lat/lon ranges and the lang enum fully documented, so the schema carries the parameter burden. The description adds no syntax or format detail for lat, lon, or lang, so baseline 3 applies.

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?

States a specific verb+resource: the populated place nearest a coordinate, plus the IANA zone of the point itself. It explicitly ties the candidate set to /geo/search, so an agent can distinguish reverse lookup from forward search without opening either schema.

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 'same list as /geo/search' phrasing implies the inverse relationship, and the sea/border/antimeridian notes tell the agent what to expect in edge cases. However, there is no explicit when-to-use/when-not statement naming alternatives such as astroway_geo_search or astroway_geo_timezone, so routing is left partly to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools