Skip to main content
Glama
Sign In

TaScan

by io.github.snowbikemike
OverviewDiscussionsAdmin

tascan_create_event

Create a new event (task list) within a project. Supports team_mode (shared completions) and multi_instance (each worker gets isolated copy — great for surveys, onboarding, info collection). team_mode and multi_instance cannot both be true.

Input Schema

NameRequiredDescriptionDefault
nameYesEvent name
team_modeNoTeam mode — shared completions
project_idYesProject ID
descriptionNoEvent description
access_levelNoSR-S2: open, assigned or secured (null = automatic)
agent_assigneeNoSR-S2: the agent_id whose key alone may reach this list and its tasks
multi_instanceNoMulti-instance — each worker gets isolated copy
assigned_worker_idsNoWorker UUIDs to assign to this event. Each gets a personal tap-to-open link. Note: a worker holds one event assignment per project — assigning moves them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / access_level
      Added value: +{
+  "description": "SR-S2: open, assigned or secured (null = automatic)",
+  "enum": [
+    "open",
+    "assigned",
+    "secured",
+    null
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedInput schema / properties / agent_assignee
      Added value: +{
+  "description": "SR-S2: the agent_id whose key alone may reach this list and its tasks",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / assigned_worker_ids
      Added value: +{
+  "description": "Worker UUIDs to assign to this event. Each gets a personal tap-to-open link. Note: a worker holds one event assignment per project — assigning moves them.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  3. Changed2 schema fields changed
    • addedInput schema / properties / multi_instance
      Added value: +{
+  "description": "Multi-instance — each worker gets isolated copy",
+  "type": "boolean"
+}
    • addedInput schema / properties / team_mode
      Added value: +{
+  "description": "Team mode — shared completions",
+  "type": "boolean"
+}
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare this is a non-idempotent, non-destructive write, so the description adds genuine value with the hard constraint 'team_mode and multi_instance cannot both be true' and semantic explanations of what each mode does (shared vs. isolated copies). It does not mention permission requirements tied to access_level or agent_assignee, which would have pushed this higher.

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?

Three sentences, front-loaded with the core action, then the two important flags, then the constraint. No filler and nothing restated from the title alone.

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 an 8-parameter creation tool with full schema descriptions and no output schema, the description covers the ambiguous behavioral choices an agent must get right. The remaining gaps (access_level semantics, assignment side effects) are documented in the schema, so nothing critical is missing.

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 100%, so the baseline is 3; the description earns above baseline by clarifying that multi_instance means each worker gets an isolated copy and naming real scenarios, plus the mutual-exclusivity rule the schema does not state. It still leaves access_level (open/assigned/secured) and agent_assignee meaning entirely to the schema.

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?

States a specific verb and resource ('Create a new event') and immediately disambiguates the domain term by glossing 'event' as '(task list) within a project'. An agent can distinguish this from tascan_create_project, tascan_update_event, and tascan_list_events without opening any 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?

Gives concrete usage guidance for the two mode flags, including when multi_instance is the right choice ('surveys, onboarding, info collection'). It stops short of naming alternative tools for related intents (e.g., tascan_apply_template or tascan_create_cycle), so it is clear but not exhaustively routable.

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
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources