TaScan

tascan_create_zone

Create a geofenced work zone. Delivery zones route workers who open the project Site Gate (geo.html?project=...) to this zone's task list when GPS places them inside the radius. Set enforce_on_list=true to zone-lock the task list — workers cannot start it from outside the zone.

Input Schema

TableJSON Schema

Name	Required	Description
`lat`	Yes	Zone center latitude
`lng`	Yes	Zone center longitude
`kind`	No	What the fence MEANS. work_site: expected here (auto clock-in, list on enter). hazard: enter allowed under conditions — required_ppe + photo checkpoint verified by AI vision, the OSHA row. containment: must stay inside; leaving = breach. restricted: must stay out; entering = breach. Default work_site.
`name`	Yes	Zone name (e.g. "Stage Left", "Loading Dock")
`polygon`	No	Polygon/rectangle zone instead of a circle: vertices as [[lat,lng], ...], at least 3. lat/lng/radius_m are then computed (centroid + bounding radius) — still pass lat/lng but they are overridden.
`radius_m`	No	Radius in meters (default 150, min 10, max 100000)
`project_id`	No	Project this zone belongs to
`description`	No	Shown to workers on the Site Gate page
`notify_email`	No	Alert recipient override — defaults to all org admins
`required_ppe`	No	Hazard zones: PPE the worker must show at entry (pick-list so the audit reads the same words)
`task_list_id`	No	Task list the Site Gate routes workers to when they are inside this zone
`auto_clock_in`	No	Writes a shift_start when the WORKER PAGE, while open, sees the phone enter the zone; detection is pull-based, there is no background geofencing. For a background-free presence event use a gate NFC/QR scan.
`enter_message`	No	What the worker sees / is texted on entry (default is generated from the rule)
`auto_clock_out`	No	Writes a shift_end when the WORKER PAGE, while open, sees the phone leave the zone; detection is pull-based, there is no background geofencing. For a background-free presence event use a gate NFC/QR scan.
`notify_on_exit`	No	Email the manager when a worker leaves this zone (accountability — sign in then disappear)
`alert_on_breach`	No	Email + SMS the admin on containment-exit / restricted-enter (default true)
`enforce_on_list`	No	Zone-lock the task list — it cannot be started from outside the radius
`notify_on_enter`	No	Email the manager when a worker enters this zone (danger areas)
`ppe_photo_required`	No	Hazard zones: pop a photo checkpoint on entry (default true when required_ppe is set)
`sms_worker_on_exit`	No	Text the worker on exit
`task_list_on_enter`	No	Task list dispatched to the worker (in-app + SMS) when they cross into the zone
`sms_worker_on_enter`	No	Text the worker the rule/list on entry, even if the app is closed

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 20, 2026

changedInput schema / properties / auto_clock_in / description

Previous value: -"Entering the zone writes a shift_start clock-in event"New value: +"Writes a shift_start when the WORKER PAGE, while open, sees the phone enter the zone; detection is pull-based, there is no background geofencing.  For a background-free presence event use a gate NFC/QR scan."

changedInput schema / properties / auto_clock_out / description

Previous value: -"Leaving the zone writes a shift_end clock-out event"New value: +"Writes a shift_end when the WORKER PAGE, while open, sees the phone leave the zone; detection is pull-based, there is no background geofencing.  For a background-free presence event use a gate NFC/QR scan."

Changed8 schema fields changedSep 3, 2026

addedInput schema / properties / alert_on_breach

Added value: +{
+  "description": "Email + SMS the admin on containment-exit / restricted-enter (default true)",
+  "type": "boolean"
+}

addedInput schema / properties / enter_message

Added value: +{
+  "description": "What the worker sees / is texted on entry (default is generated from the rule)",
+  "type": "string"
+}

addedInput schema / properties / kind

Added value: +{
+  "description": "What the fence MEANS. work_site: expected here (auto clock-in, list on enter). hazard: enter allowed under conditions — required_ppe + photo checkpoint verified by AI vision, the OSHA row. containment: must stay inside; leaving = breach. restricted: must stay out; entering = breach. Default work_site.",
+  "enum": [
+    "work_site",
+    "hazard",
+    "containment",
+    "restricted"
+  ],
+  "type": "string"
+}

addedInput schema / properties / ppe_photo_required

Added value: +{
+  "description": "Hazard zones: pop a photo checkpoint on entry (default true when required_ppe is set)",
+  "type": "boolean"
+}

addedInput schema / properties / required_ppe

Added value: +{
+  "description": "Hazard zones: PPE the worker must show at entry (pick-list so the audit reads the same words)",
+  "items": {
+    "enum": [
+      "hard_hat",
+      "safety_glasses",
+      "hi_vis_vest",
+      "gloves",
+      "steel_toe_boots",
+      "hearing_protection",
+      "harness",
+      "respirator",
+      "face_shield"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / sms_worker_on_enter

Added value: +{
+  "description": "Text the worker the rule/list on entry, even if the app is closed",
+  "type": "boolean"
+}

addedInput schema / properties / sms_worker_on_exit

Added value: +{
+  "description": "Text the worker on exit",
+  "type": "boolean"
+}

addedInput schema / properties / task_list_on_enter

Added value: +{
+  "description": "Task list dispatched to the worker (in-app + SMS) when they cross into the zone",
+  "type": "string"
+}

Changed6 schema fields changedAug 26, 2026

addedInput schema / properties / auto_clock_in

Added value: +{
+  "description": "Entering the zone writes a shift_start clock-in event",
+  "type": "boolean"
+}

addedInput schema / properties / auto_clock_out

Added value: +{
+  "description": "Leaving the zone writes a shift_end clock-out event",
+  "type": "boolean"
+}

addedInput schema / properties / notify_email

Added value: +{
+  "description": "Alert recipient override — defaults to all org admins",
+  "type": "string"
+}

addedInput schema / properties / notify_on_enter

Added value: +{
+  "description": "Email the manager when a worker enters this zone (danger areas)",
+  "type": "boolean"
+}

addedInput schema / properties / notify_on_exit

Added value: +{
+  "description": "Email the manager when a worker leaves this zone (accountability — sign in then disappear)",
+  "type": "boolean"
+}

addedInput schema / properties / polygon

Added value: +{
+  "description": "Polygon/rectangle zone instead of a circle: vertices as [[lat,lng], ...], at least 3.  lat/lng/radius_m are then computed (centroid + bounding radius) — still pass lat/lng but they are overridden.",
+  "items": {
+    "items": {
+      "type": "number"
+    },
+    "type": "array"
+  },
+  "type": "array"
+}

AddedAug 18, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the annotations, the description discloses that zones perform GPS-based task-list routing and that enforce_on_list locks the task list to workers inside the radius. It does not cover return values or auth, but annotations already establish this as a non-read-only, non-idempotent mutation. There is no contradiction with 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.

Conciseness5/5

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

The description is two sentences with the core action first and the enforcement option second. It avoids repeating schema content and contains no filler. The geo.html URL detail is specific but earns its place by clarifying the routing mechanism.

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 22-parameter creation tool, the schema carries most of the burden, and the description supplies the essential zone-routing mental model plus a key behavioral toggle. It does not state the return value, but no output schema exists and the annotations already convey the side-effect profile. This is sufficiently complete for an agent to call the tool correctly.

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?

The schema already documents all 22 parameters with 100% coverage, so the baseline is high. The description adds meaning by connecting lat/lng/radius/task_list_id to the routing behavior and by explaining why a caller would set enforce_on_list=true. It does not document parameter syntax, but the schema already does that thoroughly.

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 opens with 'Create a geofenced work zone,' a clear verb-direct object pair that identifies the resource and distinguishes this from other create_* tools. It then adds the zone's routing behavior, so an agent knows what a zone is for. No ambiguity about what this tool does.

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

Usage Guidelines3/5

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

The description explains what created zones do and highlights the enforce_on_list behavior, giving useful context. However, it never explicitly says when to use this tool versus update_zone or list_zones, and it offers no exclusions or alternatives. The selection cue is mostly carried by the tool name and the verb 'create.'

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

All TaScan 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.

tascan_create_zone

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources