AI Team OS

by CronusL-1141

Overview Schema Source Related Servers Discussions Admin

Python

Local

task_run

Put a task on a team's wall. Despite the name, nothing executes it.

Instructions

Put a task on a team's wall. Despite the name, nothing executes it.

This tool only creates the task row. Dispatch it yourself (Agent(...) / SendMessage); the sub-agent then writes progress back with task_memo_add.

Priority and horizon drive the task wall's ordering, so set them here.

Input Schema

Name	Required	Description	Default
`tags`	No	Free-form tags for filtering the wall
`model`	No	Specify model to use (optional, metadata only)
`title`	No	Task title (optional)
`fields`	No	"all" (default, compatible) / "compact" write receipt	all
`horizon`	No	"short" (default) / "mid" / "long"
`team_id`	Yes	Team ID or name
`priority`	No	"critical" / "high" / "medium" (default) / "low"
`parent_id`	No	Open top-level parent task in the team's project (optional)
`auto_start`	No	Start status only; dependencies/waiting keep it blocked, no dispatch
`depends_on`	No	Dependency task IDs — task auto-unlocks when they complete
`waiting_on`	No	User/agent wait with kind, target_id and reason (optional)
`assigned_to`	No	Agent name/id this task is meant for (optional)
`description`	Yes	Task description
`status_note`	No	Human-readable current status explanation

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.15.2Oct 14, 2026

addedInput schema / properties / auto_start

Added value: +{
+  "default": false,
+  "description": "Start status only; dependencies/waiting keep it blocked, no dispatch",
+  "type": "boolean"
+}

addedInput schema / properties / fields

Added value: +{
+  "default": "all",
+  "description": "\"all\" (default, compatible) / \"compact\" write receipt",
+  "type": "string"
+}

addedInput schema / properties / parent_id

Added value: +{
+  "default": "",
+  "description": "Open top-level parent task in the team's project (optional)",
+  "type": "string"
+}

addedInput schema / properties / status_note

Added value: +{
+  "default": "",
+  "description": "Human-readable current status explanation",
+  "type": "string"
+}

addedInput schema / properties / waiting_on

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "User/agent wait with kind, target_id and reason (optional)"
+}

Changed5 schema fields changedv1.11.2Aug 3, 2026

addedInput schema / properties / assigned_to

Added value: +{
+  "default": "",
+  "description": "Agent name/id this task is meant for (optional)",
+  "type": "string"
+}

changedInput schema / properties / depends_on / description

Previous value: -"List of dependency task IDs (optional, task auto-unlocks when dependencies complete)"New value: +"Dependency task IDs — task auto-unlocks when they complete"

addedInput schema / properties / horizon

Added value: +{
+  "default": "",
+  "description": "\"short\" (default) / \"mid\" / \"long\"",
+  "type": "string"
+}

addedInput schema / properties / priority

Added value: +{
+  "default": "",
+  "description": "\"critical\" / \"high\" / \"medium\" (default) / \"low\"",
+  "type": "string"
+}

addedInput schema / properties / tags

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Free-form tags for filtering the wall"
+}

First observedv1.9.0Jul 14, 2026

TDQS

A4.9/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it does so well. It discloses that nothing executes (critical non-obvious behavior), that dispatch is the caller's responsibility, and that priority and horizon affect wall ordering. It adds causal context beyond what the schema fields say.

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 short paragraphs, front-loaded with the key disambiguation before any secondary details. Every sentence earns its place — no filler, and the ordering of information (what it is, what it doesn't do, what to do instead) is optimal.

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?

Given 14 parameters, an output schema, and no annotations, the description supplies exactly the missing behavioral and workflow context: non-execution, manual dispatch, and ordering semantics of priority/horizon. Output schema coverage means return values needn't be explained.

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 baseline would be 3, but the description adds meaning beyond the schema by explaining that priority and horizon 'drive the task wall's ordering,' which is absent from their enum-style schema descriptions. It does not add syntax for the other 12 params, keeping it just short of 5.

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+resource ('Put a task on a team's wall') and immediately disambiguates the misleading name ('Despite the name, nothing executes it'). Against siblings like task_create, task_run, and fleet_dispatch, the description makes clear this only creates the task row and does not dispatch execution.

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

Usage Guidelines5/5

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

Explicitly says when to use it ('This tool only creates the task row') and what to do instead ('Dispatch it yourself (Agent(...) / SendMessage)'), naming the mechanism. It also directs the agent to task_memo_add for progress write-back, giving a clear workflow.

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

Deploy Server