Skip to main content
Glama
Sign In

EasyTerritory MCP

by ai.easyterritory
OverviewDiscussionsAdmin

Save to Designer

push_to_designer
Destructive

Saves a Territory Solution in EasyTerritory Designer from the server. Without project_id it creates a new rolodex project named label (the user's choice; a missing label returns CLARIFICATION_REQUIRED). With project_id it overwrites that project's territories, points, and routes in place. Input: map_session_id, ts_handle, or a completed build job_id. Returns a task; the result has project_id, url, and share_with_user. part_layer_id binds the Designer catalog layer (default: the layer a pulled TAL came from); tal_id picks the alignment; include_points=false sends territories and routes only. Route stops link to point layers by point_id. run_plugin / push_power_bi (default false) run the project's post-save plugin / refresh Power BI. Requires link_designer.

Input Schema

NameRequiredDescriptionDefault
labelNo
job_idNotask_id (same value as job_id) of a completed build or ingest task; its Territory Solution is the input.
tal_idNoAlignment to push; defaults to the active TAL.
ts_handleNoTerritory Solution reference (tsh_...) from a build, ingest_accounts, import_geojson, import_designer_project, or get_map_visualization; Territory Solutions are not accepted inline.
project_idNoDesigner project to overwrite in place; omit to create a new project named label.
run_pluginNo
part_layer_idNoDesigner catalog part layer to bind; defaults to the layer a pulled TAL came from.
push_power_biNo
include_pointsNo
map_session_idNoOpen map session (msess_...) from get_map_visualization. Its Territory Solution is the input; omit ts_handle when set.

Output Schema

NameRequiredDescriptionDefault
okYes
errorNoPresent when ok is false.
resultNoPresent when ok is true. A submission returns the task reference (task_id, next_action, sleep_ms); the completed task result carries the remaining fields.
warningsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / result / description
      Previous value: -"Present when ok is true."New value: +"Present when ok is true. A submission returns the task reference (task_id, next_action, sleep_ms); the completed task result carries the remaining fields."
    • addedOutput schema / properties / result / properties
      Added value: +{
+  "do_this_next": {
+    "type": "object"
+  },
+  "job_id": {
+    "type": "string"
+  },
+  "next_action": {
+    "type": "string"
+  },
+  "sleep_ms": {
+    "type": "integer"
+  },
+  "status": {
+    "type": "string"
+  },
+  "task_id": {
+    "type": "string"
+  },
+  "terminal": {
+    "type": "boolean"
+  }
+}
  2. Changed10 schema fields changed
    • addedInput schema / properties / job_id / description
      Added value: +"task_id (same value as job_id) of a completed build or ingest task; its Territory Solution is the input."
    • addedInput schema / properties / map_session_id / description
      Added value: +"Open map session (msess_...) from get_map_visualization. Its Territory Solution is the input; omit ts_handle when set."
    • addedInput schema / properties / part_layer_id / description
      Added value: +"Designer catalog part layer to bind; defaults to the layer a pulled TAL came from."
    • addedInput schema / properties / project_id / description
      Added value: +"Designer project to overwrite in place; omit to create a new project named label."
    • addedInput schema / properties / tal_id / description
      Added value: +"Alignment to push; defaults to the active TAL."
    • addedInput schema / properties / ts_handle / description
      Added value: +"Territory Solution reference (tsh_...) from a build, ingest_accounts, import_geojson, import_designer_project, or get_map_visualization; Territory Solutions are not accepted inline."
    • removedOutput schema / additionalProperties
      Removed value: -true
    • addedOutput schema / properties
      Added value: +{
+  "error": {
+    "description": "Present when ok is false.",
+    "properties": {
+      "ask_user": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "code": {
+        "type": "string"
+      },
+      "details": {
+        "type": "object"
+      },
+      "do_this_next": {
+        "type": "object"
+      },
+      "message": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "ok": {
+    "type": "boolean"
+  },
+  "result": {
+    "description": "Present when ok is true.",
+    "type": "object"
+  },
+  "warnings": {
+    "items": {
+      "properties": {
+        "code": {
+          "type": "string"
+        },
+        "message": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "type": "array"
+  }
+}
    • addedOutput schema / required
      Added value: +[
+  "ok"
+]
    • removedOutput schema / title
      Removed value: -"push_to_designerDictOutput"
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is partly covered. The description still earns credit by specifying exactly what is destroyed ("overwrites that project's territories, points, and routes in place"), that it is asynchronous ("Returns a task"), what the result contains, and that link_designer must be present first — real behavioral context beyond 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.

Conciseness4/5

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

The description front-loads the two modes and the input options before moving to optional flags, and every sentence carries information. It is dense — several clauses are packed per sentence and it runs longer than typical — but there is no filler or restatement of the title.

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 10-parameter, zero-required tool with branching modes and a destructive write, the description covers input selection, mode selection, key defaults, prerequisites, and the async task result (even though an output schema exists). Minor gaps remain around error cases and precedence when several input identifiers are provided simultaneously.

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 60%, so the description must compensate, and it does: it explains label as the user's chosen new-project name with a clarification fallback, part_layer_id's default of the pulled TAL's layer, include_points=false sending territories and routes only, run_plugin/push_power_bi defaulting to false, and the point_id linkage for route stops. Only a few details (e.g., interplay if multiple input identifiers are supplied at once) are left unaddressed.

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 first sentence names a specific verb and resource: saving a Territory Solution into EasyTerritory Designer. It immediately splits the two operating modes (create a new rolodex project vs. overwrite an existing project in place), which lets an agent distinguish it from siblings like import_designer_project, publish_to_dataverse, and link_designer without opening the schema.

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?

The description gives explicit branch conditions: omit project_id to create, supply project_id to overwrite, and it lists the three acceptable input sources (map_session_id, ts_handle, completed job_id). It also states the prerequisite "Requires link_designer" and the CLARIFICATION_REQUIRED outcome for a missing label. It stops short of naming an alternative sibling to use when Designer is not the target, so it is clear context rather than full when/when-not routing.

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

All EasyTerritory MCP toolsInspect
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