Skip to main content
Glama
atlasfetch-dev

atlasfetch-mcp

Official
by atlasfetch-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Look up the boundaries containing a coordinate

lookup_location
Read-only

Reverse geocode a coordinate to get its country, region, municipality, ISO 3166 codes, optional nearest street, and matches against custom boundary sets for geofence checks.

Instructions

Reverse geocode a coordinate to the administrative areas that contain it — country, region (state or province) and municipality — as names plus ISO 3166 codes, optionally the nearest street, and matches from boundary sets the account has uploaded: all in one call.

Use for: which country, region or municipality a point is in; which street a point is on (add "street" to base); geofence checks against your own polygons; tagging data with region codes. Do NOT use for: forward geocoding or place search (an address to a coordinate), routing, distances, or fetching boundary geometry.

Caveats worth repeating to the user: municipal is the finest unit AVAILABLE, not a consistent kind of thing — Los Angeles returns a city, rural Kansas returns a county, so do not assume it names a city. A layer that matched nothing comes back null. The errors array is always present: a boundary set that is unavailable or not granted to this key is skipped and reported there, while the call itself still succeeds.

STREETS (opt-in via base, worldwide). base.street is ALWAYS three answers, for 5 m, 20 m and unlimited in that order, each with radiusMeters, streetNumber, streetName, postcode and distanceMeters. A numbered address within the radius wins over a nearer street (for the unlimited entry the address must still be within 20 m); otherwise the nearest named street; unnamed roads never answer. Two different nulls: base.street === null means there is no street data for the point’s country, while an entry whose fields are null means nothing was within that radius — never report them the same way. streetNumber and postcode are STRINGS (44A, 12-14, 0181), house numbers are rare outside well-mapped areas, and no street geometry is returned.

One call is one billed lookup however many layers, sets or grid codes it touches, and a call that matches nothing still bills.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latYesLatitude, -90 to 90.
lngYesLongitude, -180 to 180.
baseNoWhich reference layers to resolve. Defaults to country, region and municipal. "street" is opt-in: add it explicitly to get the nearest street.
setsNoNames of the boundary sets on this account to match against. Defaults to none.
h3resNoH3 resolution 0-15. 9 is about 400 m across.
encodeNoAlso return the point as an H3 cell index and/or Google Plus Code. Output only — neither can be used AS a location, because both name areas rather than points.
pluslenNoPlus Code length. 9 is not a valid length. 10 is about 14 m.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.6
    • changedInput schema / properties / base / description
      Previous value: -"Which reference layers to resolve. Defaults to all three."New value: +"Which reference layers to resolve. Defaults to country, region and municipal. \"street\" is opt-in: add it explicitly to get the nearest street."
    • changedInput schema / properties / base / items / enum
      Previous value: -[
-  "country",
-  "region",
-  "municipal"
-]New value: +[
+  "country",
+  "region",
+  "municipal",
+  "street"
+]
  2. First observedv0.1.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnlyHint and openWorldHint, but the description goes far beyond them: billing is per-call even on empty matches, the errors array is always present and reports skipped/ungranted sets without failing the call, unmatched layers return null, and base.street always yields three radius answers with distinct null meanings. This is exactly the operational context annotations cannot carry.

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?

Front-loaded with purpose, then Use-for / Do-NOT-use, then caveats — a strong structure for a tool with this much behavior. It is long and the STREETS paragraph is dense, but almost every sentence carries non-obvious operational information, so it mostly earns its length.

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?

With no output schema and seven parameters, the description carries the full burden and does: it describes return shape (names plus ISO codes, street triples, h3/pluscode encodings), null semantics, partial failure via the errors array, and billing. Nothing an agent needs to call it correctly is missing.

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 materially extends several parameters: 'street' is opt-in via base, encode values are output-only and cannot serve as a location, and streetNumber/postcode are documented as strings. It does not re-explain pluslen/h3res beyond the schema, so it stops short of a 5.

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 ('reverse geocode a coordinate to the administrative areas that contain it') and enumerates the returned layers (country, region, municipal, street, uploaded sets). The sibling tools are all boundary-management operations, and this one is clearly a read/lookup, so an agent can distinguish it without opening a schema.

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?

Explicit 'Use for:' and 'Do NOT use for:' lists name concrete scenarios (region tagging, geofence checks vs. forward geocoding, routing, distances). The alternative direction (address→coordinate) is explicitly excluded, which is the exact confusion this tool would otherwise invite.

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