Skip to main content
Glama
atlasfetch-dev

atlasfetch-mcp

Official
by atlasfetch-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Add a polygon to a boundary set

add_boundary
Destructive

Add a polygon geofence to an existing boundary set so location lookups report points inside it, for delivery zones, service areas, or 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.

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.

Input Schema

TableJSON 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

A5/5.0
Behavior5/5

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

Beyond the annotations, the description reveals key non-obvious behaviors: calling twice with the same name stores two boundaries, self-intersecting geometries are rejected, plan limits cap vertices/properties/boundaries and produce a refusal message, and a full demo set silently deletes its oldest boundary. This substantially complements the destructiveHint and idempotentHint annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every paragraph earns its place: purpose, prerequisites, geometry constraints, plan limits, demo-key caveats, and return values. It is front-loaded with the core behavior and organized so an agent can scan the critical constraints quickly.

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, the description explicitly lists the returned fields: id, set, name, properties, pointCount, and createdAt. It also covers failure modes, plan limits, authentication prerequisites, and the destructive demo-key behavior, making the tool fully callable by an agent without needing external context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema coverage is 100%, the description adds meaning the schema alone does not convey: duplicate names are allowed, every position including the closing one counts toward vertex limits, a MultiPolygon must be split into separate calls, and properties are restricted per plan. The geometry constraints and example also reinforce the schema's coordinate-order and closed-ring requirements.

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?

The description names a specific verb ('Adds'), a specific resource ('ONE polygon to an existing boundary set'), and a concrete effect on lookup_location. It clearly distinguishes itself from create_boundary_set by requiring the set to already exist, and from lookup_location by stating it is the tool that makes containment reportable.

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 before-calling prerequisites are given: the set must already exist via create_boundary_set, and it must be switched on and granted to an API key in the dashboard. It also gives a clear when-not-to-use instruction for MultiPolygons ('add each part separately') and warns against using the shared demo key for private data.

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