Skip to main content
Glama
atlasfetch-dev

atlasfetch-mcp

Official
by atlasfetch-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Add a polygon to a boundary set

add_boundary
Destructive

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.

Instructions

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.

A polygon may have at most 50 points on EVERY plan, the closing one included; more is refused, unbilled, with advice to simplify the shape or split it into several boundaries. Plan limits cap properties per boundary and boundaries per set. WITHOUT YOUR OWN KEY, the shared demo key is on the Public plan: 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.

Input Schema

NameRequiredDescriptionDefault
setYesName of an existing set on this account (see list_boundary_sets).
nameYesLabel returned when a looked-up point falls inside this polygon, e.g. "Zone A".
geometryYesA GeoJSON Polygon, e.g. {"type":"Polygon","coordinates":[[[18.40,-33.93],[18.40,-33.90],[18.44,-33.90],[18.44,-33.93],[18.40,-33.93]]]}.
propertiesNoOptional flat key/value pairs returned with every match: keys up to 32 characters, values a string (up to 256 characters), number or boolean. The demo key accepts only category, color and priority, from fixed lists.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changedv0.1.4
    • removedInput schema / properties / geometry / additionalProperties
      Removed value: -{}
    • changedInput schema / properties / geometry / description
      Previous value: -"GeoJSON geometry, e.g. {\"type\":\"Polygon\",\"coordinates\":[[[lng,lat],...]]}. Longitude comes first. A Feature or FeatureCollection is not accepted."New value: +"A GeoJSON Polygon, e.g. {\"type\":\"Polygon\",\"coordinates\":[[[18.40,-33.93],[18.40,-33.90],[18.44,-33.90],[18.44,-33.93],[18.40,-33.93]]]}."
    • addedInput schema / properties / geometry / properties
      Added value: +{
+  "coordinates": {
+    "description": "Rings of [longitude, latitude] positions. The first ring is the outline; any further rings are holes. Each ring is closed: its last position repeats its first.",
+    "items": {
+      "items": {
+        "items": {
+          "type": "number"
+        },
+        "maxItems": 3,
+        "minItems": 2,
+        "type": "array"
+      },
+      "minItems": 4,
+      "type": "array"
+    },
+    "minItems": 1,
+    "type": "array"
+  },
+  "type": {
+    "const": "Polygon",
+    "type": "string"
+  }
+}
    • removedInput schema / properties / geometry / propertyNames
      Removed value: -{
-  "type": "string"
-}
    • addedInput schema / properties / geometry / required
      Added value: +[
+  "type",
+  "coordinates"
+]
    • changedInput schema / properties / name / description
      Previous value: -"A name for this boundary, returned on a match."New value: +"Label returned when a looked-up point falls inside this polygon, e.g. \"Zone A\"."
    • addedInput schema / properties / properties / additionalProperties / anyOf
      Added value: +[
+  {
+    "maxLength": 256,
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  }
+]
    • changedInput schema / properties / properties / description
      Previous value: -"Flat key/value pairs returned with every match of this boundary."New value: +"Optional flat key/value pairs returned with every match: keys up to 32 characters, values a string (up to 256 characters), number or boolean. The demo key accepts only category, color and priority, from fixed lists."
    • addedInput schema / properties / properties / propertyNames / maxLength
      Added value: +32
    • changedInput schema / properties / set / description
      Previous value: -"The set to add it to. It must already exist."New value: +"Name of an existing set on this account (see list_boundary_sets)."
    • removedInput schema / properties / set / maxLength
      Removed value: -32
    • removedInput schema / properties / set / minLength
      Removed value: -1
    • addedInput schema / properties / set / pattern
      Added value: +"^[a-zA-Z0-9][a-zA-Z0-9_-]{0,31}$"
  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 destructiveHint=true and idempotentHint=false, and the description explains exactly why: repeated calls with the same name store duplicates, and adding to a full demo set silently deletes the oldest boundary. It also discloses rejection behavior (self-intersecting shapes, >50 points refused unbilled) that the annotations cannot express.

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 the core action and the lookup consequence, then proceeds through prerequisites, geometry rules, plan limits and return shape in a logical order. It is long, but nearly every sentence carries a constraint the agent needs; the demo-key paragraph is the only slightly bloated section.

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?

There is no output schema, yet the description names the returned fields (id, set, name, properties, pointCount, createdAt). Combined with prerequisites, geometry limits and failure modes, an agent has everything needed to call it correctly and interpret the result.

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 schema already documents ring closure and [longitude, latitude] ordering. The description nonetheless adds constraints not present in the schema: geometry must be a single Polygon (not MultiPolygon/Feature/FeatureCollection), a hard 50-point cap on every plan including the closing point, and demo-key restrictions on properties values.

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 and resource ('Adds ONE polygon to an existing boundary set') and ties it to the downstream effect on lookup_location. It is clearly distinguished from create_boundary_set and update_boundary by the 'each call creates a new boundary' wording.

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?

Explicitly names the prerequisite tool (create_boundary_set), the dashboard step required before lookups match, and the alternative action for MultiPolygons (add each part separately) or oversized shapes (simplify or split). It also scopes demo-key usage with a 'never upload anything private' warning.

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