Skip to main content
Glama

TaScan

by io.github.snowbikemike

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
NameRequiredDescriptionDefault
latYesZone center latitude
lngYesZone center longitude
kindNoWhat 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.
nameYesZone name (e.g. "Stage Left", "Loading Dock")
polygonNoPolygon/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_mNoRadius in meters (default 150, min 10, max 100000)
project_idNoProject this zone belongs to
descriptionNoShown to workers on the Site Gate page
notify_emailNoAlert recipient override — defaults to all org admins
required_ppeNoHazard zones: PPE the worker must show at entry (pick-list so the audit reads the same words)
task_list_idNoTask list the Site Gate routes workers to when they are inside this zone
auto_clock_inNoEntering the zone writes a shift_start clock-in event
enter_messageNoWhat the worker sees / is texted on entry (default is generated from the rule)
auto_clock_outNoLeaving the zone writes a shift_end clock-out event
notify_on_exitNoEmail the manager when a worker leaves this zone (accountability — sign in then disappear)
alert_on_breachNoEmail + SMS the admin on containment-exit / restricted-enter (default true)
enforce_on_listNoZone-lock the task list — it cannot be started from outside the radius
notify_on_enterNoEmail the manager when a worker enters this zone (danger areas)
ppe_photo_requiredNoHazard zones: pop a photo checkpoint on entry (default true when required_ppe is set)
sms_worker_on_exitNoText the worker on exit
task_list_on_enterNoTask list dispatched to the worker (in-app + SMS) when they cross into the zone
sms_worker_on_enterNoText the worker the rule/list on entry, even if the app is closed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations establish the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds behavioral consequences beyond those hints: the Site Gate routing mechanism and the enforce_on_list=true zone-lock effect. It stops short of disclosing creation-time side effects like auto_clock_in events or alert emails, but the primary operational behavior is transparent.

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?

Three sentences with the purpose statement front-loaded in the first clause. Compact and readable; the only mild redundancy is the enforce_on_list sentence, which duplicates information already present in the schema.

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 tool with no output schema, the description conveys the core operational behavior (geofenced routing and list-locking) while the richly documented schema covers parameter detail. It is sufficient for correct invocation, though it offers no return-value signal or duplicate-creation caution (the latter is partially mitigated by idempotentHint=false).

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%, so all 22 parameters are already documented and the baseline is 3. The description's only parameter-specific content ('Set enforce_on_list=true to zone-lock the task list') largely restates the schema's own description of enforce_on_list rather than adding new meaning.

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?

Opens with a specific verb+resource ('Create a geofenced work zone') and defines the entity's behavior: routing Site Gate workers to the zone's task list when GPS places them inside the radius. This clearly distinguishes it from the create_* siblings such as create_project, create_worker, and create_event without needing to open 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 Guidelines3/5

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

The description implies when to use it by explaining what zones do (delivery routing from Site Gate), but it gives no explicit when/when-not conditions and never names alternatives such as tascan_update_zone for modifying an existing zone or tascan_list_zones for viewing them. Usage context exists, but decision criteria are left to inference.

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

All TaScan toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation4/5

Most tools map to a distinct resource+action pair, and the descriptions clearly separate entities like tasks, subtasks, workers, invoices, zones, assets, and reports. A few close pairs (get_report vs generate_report, dispatch_instruction vs dispatch_to_agent, analyze_issue vs auto_resolve) require careful reading, but the descriptions are detailed enough to disambiguate them.

Naming Consistency4/5

The vast majority follow a tascan_verb_noun pattern with consistent create/get/list/update/delete verbs. Minor deviations like condition_history, server_info, zone_compliance, and one-word find slightly break the otherwise predictable pattern.

Tool Count1/5

At 69 tools, this is far beyond what an agent can efficiently consider, and it bundles several distinct domains into one MCP surface. Even if each tool is individually useful, the combined set is an extreme mismatch for a coherent tool interface.

Completeness4/5

The surface covers nearly the full lifecycle for projects, events, tasks, subtasks, workers, reports, invoices, zones, assets, issues, and communications. Minor gaps exist (no explicit asset updates/decommissioning, no cancel_invite, no delete_zone), but the main workflows have no dead ends.

Resources