EasyTerritory MCP

Discover Workflow Intent

discover_intent

Read-onlyIdempotent

Maps a free-text territory request to a workflow. Read-only keyword routing; no compute. Returns intent_category, the recommended tool order, the main tool (tier1_tool, null when the request is ambiguous) and alternatives, required_inputs, clarifying_questions for missing inputs, and the workflow guide inline as guidance {uri, title, excerpt}. Covers building territories (auto_build, account_build, direct_build, cluster_points, seed_build), editing (realign, split, merge, rebalance), analyze, geocoding and ingest, showing a ZIP or part layer, routes, drive-time areas (isochrone_build), recurring visit schedules (schedule_visits), contractor coverage gaps (analyze_network_coverage), listing points in a territory (points_in_territory), and moving a Territory Solution to or from EasyTerritory Designer.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "user_request": "<user_request>"
    },
    "name": "discover_intent"
  }
}

Input Schema

Name	Required	Description	Default
`context`	No	Optional state flags that tailor the recommended workflow.
`user_request`	Yes	The raw natural-language request to classify.

Output Schema

Name	Required	Description
`ok`	Yes
`error`	No	Present when ok is false.
`result`	No	Present when ok is true.
`warnings`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 1, 2026

changedInput schema / properties / context / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "properties": {
+      "has_point_layer": {
+        "type": "boolean"
+      },
+      "has_ts_handle": {
+        "type": "boolean"
+      },
+      "has_visit_frequency_field": {
+        "description": "True when the active point layer declares a visit-frequency column. Appends the route-vs-schedule question on route_stops / periodic_scheduling and the use-or-ignore question on build_from_accounts / account_grouping.",
+        "type": "boolean"
+      },
+      "part_layers_loaded": {
+        "type": "boolean"
+      },
+      "viewer_connected": {
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / context / description

Added value: +"Optional state flags that tailor the recommended workflow."

removedInput schema / properties / context / title
```
Removed value: -"Context"
```

addedInput schema / properties / user_request / description

Added value: +"The raw natural-language request to classify."

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.",
+    "properties": {
+      "clarifying_questions": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "confidence": {
+        "type": "string"
+      },
+      "guidance": {
+        "type": [
+          "null",
+          "object"
+        ]
+      },
+      "guidance_uri": {
+        "type": "string"
+      },
+      "intent_category": {
+        "type": "string"
+      },
+      "matched_signals": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "mc_first_required": {
+        "type": "boolean"
+      },
+      "recommended_workflow": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "required_inputs": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "resolved_part_layer": {
+        "type": [
+          "null",
+          "string"
+        ]
+      },
+      "tier1_tool": {
+        "type": [
+          "null",
+          "string"
+        ]
+      },
+      "tier2_alternatives": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      }
+    },
+    "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: -"discover_intentDictOutput"

First observedSep 29, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, closed-world and non-destructive, so the safety profile is covered. The description still adds real behavior: 'keyword routing; no compute' tells the agent this is a cheap deterministic classifier, and 'tier1_tool, null when the request is ambiguous' plus 'clarifying_questions for missing inputs' discloses the failure/ambiguity branch the agent must handle.

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 core statement and the 'no compute' constraint are front-loaded, then the return shape, then the coverage list. Dense but every clause carries information an agent needs; the long intent enumeration doubles as routing vocabulary rather than filler.

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 a full output schema and complete parameter documentation, the description supplies what structured fields cannot: that this is a non-computing router, the ambiguity path, and the exact set of workflows it recognizes. Nothing required to invoke it correctly is absent.

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

Parameters3/5

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

Schema description coverage is 100% and the context object's flags are individually documented in the schema, so the baseline applies. The description contributes only indirectly, via the list of supported intents that implicitly defines the vocabulary of user_request; it says nothing about how context flags alter routing beyond what the schema already states.

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 specific verb and resource: 'Maps a free-text territory request to a workflow', plus a scoping qualifier 'read-only keyword routing; no compute'. It distinguishes itself from the build/analyze siblings by being a router, but never differentiates itself from the closest sibling, workflow_advisor, which an agent could plausibly pick instead.

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 enumeration of covered request categories (build, edit, analyze, geocode, isochrone, scheduling, Designer transfer) effectively tells an agent which requests belong here. What is missing is sequencing guidance — no statement that this should be called before dispatching to the recommended tool, and no exclusion pointing at workflow_advisor.

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?