atlasfetch-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ATLASFETCH_API_KEY | No | Your AtlasFetch API key. Defaults to a shared demo key if not provided. | |
| ATLASFETCH_API_URL | No | Override the API URL for local or staging APIs. | https://api.atlasfetch.xyz |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| lookup_locationA | 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. |
| list_boundary_setsA | Lists the boundary sets on this account with their boundary counts and the API keys (id and label) each is granted to. A set only matches during a lookup when it is available AND granted to the key making the call. |
| create_boundary_setA | Creates an empty named set to hold your own polygons: delivery zones, service areas, sales territories. IMPORTANT, and not a bug: a new set is created unavailable and granted to no key, so it matches nothing until both are changed. Granting is addressed by API key id, and the only endpoint that lists key ids needs a browser session — which this server does not have. So this tool can create the set and add boundaries to it, but CANNOT make it queryable. Tell the user to finish that at https://atlasfetch.xyz/dashboard. |
| add_boundaryA | Adds ONE polygon to an existing boundary set on this account, so that lookup_location reports when a point falls inside it — delivery zones, service areas, sales territories. Each call creates a new boundary: calling twice with the same name stores two. Before calling: the set must already exist (create_boundary_set). A set matches nothing in lookups until it is switched on and granted to an API key in the dashboard at https://atlasfetch.xyz/dashboard, which this server cannot do. geometry must be a single GeoJSON Polygon — not a MultiPolygon, Feature or FeatureCollection. Positions are [longitude, latitude]. Each ring needs at least 4 positions and must be closed (last position equals the first); extra rings are holes. Self-intersecting shapes are rejected. To store a MultiPolygon, add each part separately. Plan limits cap vertices per polygon (every position counts, including the closing one), properties per boundary and boundaries per set; a limit hit is refused with a message naming it. WITHOUT YOUR OWN KEY, the shared demo key is on the Public plan: at most 5 positions per polygon (a closed quadrilateral), properties only category (zone, area, route, place, other), color (green, blue, red, yellow, purple, orange) and priority (low, medium, high), and one set shared with every demo user, where adding to a full set silently deletes its oldest boundary. Never upload anything private with the demo key. Returns the stored boundary: id, set, name, properties, pointCount and createdAt. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: creating a set, adding a boundary to an existing set, listing sets, and performing a reverse geocode/boundary lookup. There is no overlap in action or resource, so an agent can select the right tool without ambiguity.
All four tools follow a consistent snake_case verb_noun pattern: add_boundary, lookup_location, create_boundary_set, list_boundary_sets. The convention is predictable and readable throughout.
Four tools is a reasonable count for a focused geocoding and boundary-upload service, and each tool earns its place. However, the set is a bit thin for boundary management, missing even basic inspection or cleanup operations.
The surface covers creating sets, adding boundaries, listing sets, and lookups, but there is no way to delete or update a boundary or set, nor to list the individual boundaries inside a set. These are significant gaps that will prevent agents from managing or cleaning up boundary data.