Skip to main content
Glama
atlasfetch-dev

atlasfetch-mcp

Official

Geocode an address to a coordinate (South Africa)

geocode_address
Read-only

Convert a single address into a coordinate and precision level for delivery dispatch, showing whether the house, street, intersection, or locality was found.

Instructions

Turn ONE address into a point, with an honest account of how much of it was found. Built for deliveries. South Africa today; more countries as their data loads. 1 lookup per address, found or not.

Send either q (one line) or address (housenumber, street, suburb, city, postcode, unit) — never both. If the address is already split, send it split: it matches better.

READ precision BEFORE using the point. "address" means the house was found; "interpolated" means it was estimated between the numbers either side; "intersection" means a street corner ("Cnr Main Rd and Belmont Rd", "Bree & Strand Streets"), at the point where the two meet, with the second street in matched.crossStreet; "site" means a named site — a shopping centre, office park, complex or estate, hospital, school, airport or hotel — at a point inside it, named in matched.site; "street" means the right street but NOT the house; "locality" means only the suburb or town. NEVER present a street- or locality-level point as a door: a driver sent there will be at the wrong house. In South Africa most answers are street-level, because OpenStreetMap has house numbers on about 13% of street names — that is the data being honest, not a failure.

What to do with an answer — the result line says which applies:

  • address, interpolated, intersection or site, not ambiguous, confidence 0.5 or more: dispatch. For a site, pass on the unit or shop number from the original address ("Shop 12") — the answer does not include it, and the driver needs it.

  • street: ask the recipient for a pin or a landmark.

  • ambiguous, or locality: ask the customer before dispatching. confidence ranks answers; it is NOT a probability. ambiguous means a same-named street elsewhere scored about as well, or the street was a near-miss spelling with no house number to confirm it. result null means nothing trustworthy was found, and that still costs the lookup.

Some addresses name something that cannot be placed: an erf, stand, plot or farm portion (land parcels — there is no cadastre), a township stand, a PO box or private bag. Those parts come back in unmatched and the answer is the place named, at locality: ask the customer for a street address.

country is a hard filter; region (ZA-WC, or "Western Cape") only ranks streets inside it first, so a wrong province does not lose the address. An uncovered country is refused, unbilled, with the list of covered countries in the message — that message is the live coverage list; there is no other. sets and base answer "which delivery zone is it in" in the same call, at no extra cost.

One address per call, deliberately. For a delivery list, call this once per row so the user sees what is being spent; programs with thousands of rows should use the API’s POST /geocode/batch directly. Not for: searching for a business or landmark by name, or a coordinate to an address (that is lookup_location with the street layer).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoThe whole address on one line, e.g. "25 Adderley Street, Cape Town".
baseNoAdministrative layers to resolve at the found point.
setsNoBoundary sets on this account to match at the found point, e.g. delivery zones.
regionNoISO 3166-2 ("ZA-WC") or a name ("Western Cape"). A preference, not a filter.
addressNoThe address already split into parts. Needs at least a street. Use instead of q.
countryNoISO 3166-1 alpha-2, e.g. "ZA". A hard filter: only that country is searched.
streetGeometryNoThe matched street’s line, trimmed to about 250 m. Only if something will draw it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint, so the description carries the operational burden and does so well: it discloses cost behavior (1 lookup per address even on failure, uncovered countries refused unbilled), the meaning of confidence vs probability, and the fact that ~87% of ZA addresses resolve only to street level. These are traits the annotations do not convey.

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?

Strongly front-loaded with the core contract. It is long, and a few passages (the shop-number aside, the repeated street/locality warnings) go beyond strict necessity, but nearly every sentence carries operational value for a genuinely complex geocoding contract.

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 explains the return surface an agent needs: precision values, matched.crossStreet/matched.site, unmatched parts, confidence, and result null semantics. For a 7-param tool with nested objects this is complete enough to call and interpret correctly.

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 genuine meaning beyond it: q vs address are mutually exclusive ('never both'), country is a hard filter while region only ranks, and sets/base return zones at no extra cost. Some of this restates the schema (e.g. region 'a preference, not a filter'), keeping it 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 (turn ONE address into a point) and immediately distinguishes itself from siblings by naming lookup_location for reverse geocoding. It also carves out an explicit non-goal (business/landmark name search) so the agent can route correctly without opening any 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?

Gives explicit when-to-use and when-not rules: dispatch criteria keyed to precision/confidence, when to ask the customer, when to use the batch API instead, and what is out of scope. It routes the agent to a concrete alternative (POST /geocode/batch) for multi-row programs.

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