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, and match it against boundary sets the account has uploaded, in the same call. Use for: which country, region or municipality a point is in; geofence checks against your own polygons; tagging data with region codes. Do NOT use for: street addresses or postcodes (this is not forward geocoding, and results stop at the municipality), 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. 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 targets a distinct operation: listing sets, performing a lookup, creating a set, and adding a polygon. The boundary-set vs boundary distinction is clear from names and descriptions, so an agent is unlikely to select the wrong tool.
All tool names follow a consistent lowercase verb_noun pattern: list_boundary_sets, lookup_location, create_boundary_set, add_boundary. There are no mixed casing or vague verb variations.
Four tools is a well-scoped set for a focused geofencing/reverse-geocoding server. Each tool covers a necessary step in the core workflow without redundant additions.
The set is missing obvious lifecycle operations: boundaries and sets cannot be updated, deleted, or listed individually, and newly created sets cannot be activated or granted to API keys from this server, forcing a manual dashboard step. This leaves agents with a one-way create-and-add workflow and no way to correct mistakes or complete the queryability setup.