EasyTerritory MCP

Auto-Build Territories

auto_build

Destructive

Partitions ingested account points into balanced sales territories with equal workload, metric, or count over a part layer (e.g. ZIPs) as a new alignment (TAL). Needs the user's choices: build_mode (fixed_territory_count + territory_count, fixed_workload_target + target_workload hours, or scoped_split), objective (workload_bias for drive time + dwell; metric + metric_bias for a column such as Revenue; biases sum to 100), and dwell_time (a column or a stated scalar). Each missing choice returns CLARIFICATION_REQUIRED with ask_user; a declared visit-frequency column also needs visit_frequency_field or ignore_visit_frequency. part_scope: bbox_intersect (default; parts near the accounts, can reach national scale) or explicit with part_filter, e.g. {state_abbr: TX}. The filter limits parts; accounts outside it stay on the layer, unassigned (UNASSIGNED_ACCOUNTS). With map_session_id the open map is the input. Returns a task; national builds take minutes and estimated_remaining_ms is capped, not a forecast. The result carries tal_id, ts_handle, and phase_timings_ms; analyze has statistics.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ts`	No
`part_ids`	No
`objective`	No
`tal_label`	Yes
`ts_handle`	No
`build_mode`	No
`dwell_time`	No
`part_layer`	Yes
`part_scope`	No
`output_mode`	No	tal is the default. assignments returns assignments_artifact plus an authenticated download_url; no ts_handle, tal_id, or map_refresh.	tal
`part_filter`	No
`point_layer`	Yes
`repair_policy`	No	Topology repair for dissolved territories. default fills interior holes in the dissolved geometry (no part is added or reassigned; repair_summary.changed_part_ids lists the territories' own parts). report_only detects holes and changes nothing (warning REPAIR_AVAILABLE). strict fails with REPAIR_REQUIRED when a hole is found.	default
`map_session_id`	No
`expected_revision`	No
`visit_frequency_field`	No
`ignore_visit_frequency`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

changedInput schema / properties / objective / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "description": "Balance objective: {metric: '<column>|__account_count__', workload_bias: 0..100, metric_bias: 0..100}. Biases sum to 100. For pure metric balance, pass {metric: '<column>', workload_bias: 0, metric_bias: 100} (or {metric: '<column>'} on restructure tools). When omitted on restructure tools, inherits the source TAL build_provenance objective or seed_build target.",
+    "properties": {
+      "metric": {
+        "description": "Point metric column name to balance (e.g. 'Revenue', 'weekly_volume'), or '__account_count__' for location-count balance.",
+        "type": "string"
+      },
+      "metric_bias": {
+        "description": "Weight (0..100) on the metric or location-count dimension.",
+        "maximum": 100,
+        "minimum": 0,
+        "type": "integer"
+      },
+      "workload_bias": {
+        "description": "Weight (0..100) on workload (drive time + dwell).",
+        "maximum": 100,
+        "minimum": 0,
+        "type": "integer"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

Changed1 schema field changedOct 14, 2026

changedInput schema / properties / dwell_time / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "description": "Onsite (dwell) time per visit: {type: 'scalar', value: <number>, unit: 'minutes'|'hours'} or {type: 'field', field: '<column>', unit: 'minutes'|'hours'}.",
+    "properties": {
+      "field": {
+        "description": "Point column name holding per-account onsite time when type='field'.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "type": {
+        "description": "Dwell source: 'scalar' for a fixed per-visit duration or 'field' for an ingested point column.",
+        "enum": [
+          "scalar",
+          "field"
+        ],
+        "type": "string"
+      },
+      "unit": {
+        "default": "minutes",
+        "description": "Time unit for value or field ('minutes' or 'hours').",
+        "enum": [
+          "minutes",
+          "hours"
+        ],
+        "type": "string"
+      },
+      "value": {
+        "description": "Confirmed onsite duration per visit when type='scalar'.",
+        "minimum": 0,
+        "type": "number"
+      }
+    },
+    "required": [
+      "type"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

Changed1 schema field changedOct 9, 2026

removedInput schema / properties / guidance_handle

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Guidance Handle"
-}

Changed2 schema fields changedOct 5, 2026

addedInput schema / properties / repair_policy / description

Added value: +"Topology repair for dissolved territories. default fills interior holes in the dissolved geometry (no part is added or reassigned; repair_summary.changed_part_ids lists the territories' own parts). report_only detects holes and changes nothing (warning REPAIR_AVAILABLE). strict fails with REPAIR_REQUIRED when a hole is found."

addedInput schema / properties / repair_policy / enum

Added value: +[
+  "default",
+  "strict",
+  "report_only"
+]

First observedSep 29, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Goes beyond the annotations (destructiveHint/openWorldHint/idempotentHint) by disclosing that it returns a task, that national builds take minutes, that estimated_remaining_ms is capped and not a forecast, what the result carries (tal_id, ts_handle, phase_timings_ms), and that analyze provides statistics. This is real behavioral context not present in the annotations.

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

Conciseness3/5

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

Purpose is front-loaded, but the body is a dense, comma-spliced paragraph stacking many parenthetical clauses, which makes it harder to scan for a single decision. The information is largely warranted for a 17-param tool, but the structure could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, non-idempotent, destructive build tool with 17 parameters and an output schema, the description covers the decision-critical inputs and the async/task nature well, so an agent could invoke it and know how to respond to CLARIFICATION_REQUIRED. Remaining gaps are peripheral params rather than core flow.

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?

With schema coverage at only 12%, the description carries the load and does so for the key knobs: build_mode variants, objective bias semantics ('biases sum to 100'), dwell_time as column-or-scalar, part_scope defaults, and the visit_frequency_field/ignore_visit_frequency requirement. Still, several parameters (tal_label, ts, ts_handle, part_ids, expected_revision) are left unexplained in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource: 'Partitions ingested account points into balanced sales territories ... as a new alignment (TAL)', with the balancing dimensions spelled out. It does not, however, distinguish itself from sibling builders like direct_build, seed_build, or account_build, so an agent cannot fully tell why it should pick auto_build over them from the text alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete usage context: which choices must be supplied (build_mode, objective, dwell_time), that missing choices trigger CLARIFICATION_REQUIRED with ask_user, that map_session_id makes the open map the input, and how part_scope/part_filter behave. It omits any explicit 'use this instead of X' routing against the other build tools.

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

All EasyTerritory MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?