Artel

task_create

Create a task in Artel for an agent to pick up, with priority, dependencies, and expected outcome, so work continues across sessions.

Instructions

DEPRECATED: the harness owns this now, Claude Code discovers peers and manages its own task list. Still works; not where new work should go.

Create a task for yourself or another agent to pick up.

Use when there's a discrete unit of work that should be tracked, may be done by a different agent, or needs to survive across sessions. Check task_list() for duplicates before creating.

Args: title: Short imperative description, e.g. "Fix auth token expiry bug". description: Context, acceptance criteria, or relevant links. expected_outcome: What done looks like, specific, observable result. project: Project scope. Defaults to MCP_PROJECT if set. priority: low, normal (default), or high. tags: Labels for filtering, e.g. ["writing", "infra"]. depends_on: Task IDs that must be completed before this task is unblocked. completion_contract: Optional shape the completing agent's structured output must match. When set, task_complete() REJECTS a completion whose output is missing or malformed, use it when something downstream consumes the result (e.g. one follow-up task per discovered item). Omit for ordinary tasks. Supported subset of JSON Schema: type (object/array/string/number/integer/boolean), required, properties, items, enum, minItems, minLength. Example: {"type": "object", "required": ["sources"], "properties": {"sources": {"type": "array", "minItems": 1, "items": {"type": "object", "required": ["name", "url"]}}}}

Input Schema

TableJSON Schema

Name	Required	Description	Default
`tags`	No	Labels for filtering, e.g. ["writing", "infra"].
`title`	Yes	Short imperative description, e.g. "Fix auth token expiry bug".
`project`	No	Project scope. Defaults to MCP_PROJECT if set.
`priority`	No	low, normal (default), or high.	normal
`depends_on`	No	Task IDs that must be completed before this task is unblocked.
`description`	No	Context, acceptance criteria, or relevant links.
`expected_outcome`	No	What done looks like, specific, observable result.
`completion_contract`	No	Optional shape the completing agent's structured output must match. When set, task_complete() REJECTS a completion whose output is missing or malformed, use it when something downstream consumes the result (e.g. one follow-up task per discovered item). Omit for ordinary tasks. Supported subset of JSON Schema: type (object/array/string/number/integer/boolean), required, properties, items, enum, minItems, minLength. Example: {"type": "object", "required": ["sources"], "properties": {"sources": {"type": "array", "minItems": 1, "items": {"type": "object", "required": ["name", "url"]}}}}

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.47.0Sep 24, 2026

addedInput schema / properties / completion_contract

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional shape the completing agent's structured output must match. When set, task_complete() REJECTS a completion whose output is missing or malformed, use it when something downstream consumes the result (e.g. one follow-up task per discovered item). Omit for ordinary tasks. Supported subset of JSON Schema: type (object/array/string/number/integer/boolean), required, properties, items, enum, minItems, minLength. Example: {\"type\": \"object\", \"required\": [\"sources\"], \"properties\": {\"sources\": {\"type\": \"array\", \"minItems\": 1, \"items\": {\"type\": \"object\", \"required\": [\"name\", \"url\"]}}}}",
+  "title": "Completion Contract"
+}

changedInput schema / properties / expected_outcome / description

Previous value: -"What done looks like — specific, observable result."New value: +"What done looks like, specific, observable result."

Changed1 schema field changedv0.40.1Jul 27, 2026

addedInput schema / properties / depends_on

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Task IDs that must be completed before this task is unblocked.",
+  "title": "Depends On"
+}

Changed1 schema field changedv0.17.7May 28, 2026

addedInput schema / properties / tags

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Labels for filtering, e.g. [\"writing\", \"infra\"].",
+  "title": "Tags"
+}

Addedv0.17.0May 27, 2026
Removedv0.16.1May 21, 2026
Addedv0.9.0May 16, 2026
Removedv0.7.0May 15, 2026
First observedv0.1.0May 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The annotations only declare openWorldHint=false and destructiveHint=false, so the description carries the behavioral burden. It adds valuable context: the tool is deprecated but still operational, persists tasks across sessions, and setting completion_contract causes task_complete() to reject malformed or missing output. 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.

Conciseness4/5

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

The description is front-loaded with the deprecation warning and usage conditions, and it is organized clearly with a separate Args block. Some of that block is redundant with the input schema, but the complex completion_contract parameter and the cross-tool behavior with task_complete earn the extra detail. Overall it is appropriately sized for an 8-parameter tool.

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?

The description covers the tool's deprecation, when to use it, duplicate-checking, persistence, and the completion-contract interaction with task_complete. All parameters are explained in either the description or the schema, and the context signal indicates an output schema exists, so return-value documentation is not needed. Nothing appears missing for an agent to call this tool correctly.

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 the schema already documents all eight parameters. The Args section largely paraphrases the schema and adds little new semantic meaning for most fields; even the completion_contract behavior and example are already present in the schema. This meets the baseline 3 because the description does not need to compensate for schema gaps, but it also does not substantially exceed 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?

The description opens with a deprecation warning but immediately states the exact verb and resource: 'Create a task for yourself or another agent to pick up.' It clearly distinguishes the tool from task_list and task_complete by referencing duplicate-checking and the completion contract, and from most siblings by framing this as the creation path. The deprecation line adds a strong identity signal without obscuring what the 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 Guidelines5/5

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

The description explicitly says 'Use when there's a discrete unit of work that should be tracked, may be done by a different agent, or needs to survive across sessions.' It also provides a concrete alternative check: 'Check task_list() for duplicates before creating.' The deprecation warning supplies a clear when-not-to-use signal, so the agent can decide whether to prefer the harness functionality instead.

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