Artel

task_complete

Mark a claimed task as completed, recording a summary and structured output for all agents to review.

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.

Mark your claimed task as completed. Only the claiming agent can complete it.

Call when the task's expected_outcome has been fully achieved. The body is recorded in the task's comment log and visible to all agents reviewing the task. If you cannot finish the task, use task_fail() instead; if you are stepping away mid-work, use task_unclaim() so another agent can pick it up.

Args: task_id: ID of a task you have claimed. body: Summary of what was accomplished, including follow-up IDs or links. Recommended, it is the only record future agents have of what was done. output: Structured result of the work. Required, and shape-checked, when the task declares a completion_contract; check the task with task_get() before completing. Completion is REJECTED if it is missing or does not match. Optional otherwise, in which case it is stored as-is.

Input Schema

TableJSON Schema

Name	Required	Description
`body`	No	Summary of what was accomplished, including follow-up IDs or links. Recommended, it is the only record future agents have of what was done.
`output`	No	Structured result of the work. Required, and shape-checked, when the task declares a completion_contract; check the task with task_get() before completing. Completion is REJECTED if it is missing or does not match. Optional otherwise, in which case it is stored as-is.
`task_id`	Yes	ID of a task you have claimed.

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

changedInput schema / properties / body / description

Previous value: -"Summary of what was accomplished, including follow-up IDs or links. Recommended — it is the only record future agents have of what was done."New value: +"Summary of what was accomplished, including follow-up IDs or links. Recommended, it is the only record future agents have of what was done."

addedInput schema / properties / output

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Structured result of the work. Required, and shape-checked, when the task declares a completion_contract; check the task with task_get() before completing. Completion is REJECTED if it is missing or does not match. Optional otherwise, in which case it is stored as-is.",
+  "title": "Output"
+}

Addedv0.17.0May 27, 2026
Removedv0.16.1May 21, 2026
Addedv0.9.0May 16, 2026
Removedv0.7.0May 15, 2026

Changed1 schema field changedMay 13, 2026

addedInput schema / properties / body

Added value: +{
+  "default": "",
+  "title": "Body",
+  "type": "string"
+}

First observedv0.1.0May 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations are minimal (destructiveHint=false, openWorldHint=false), so the description carries the full burden. It discloses critical side effects: the body is recorded in the task's comment log and visible to all agents, the output is shape-checked and can cause rejection if missing/mismatched when a completion_contract exists, and only the claiming agent may complete. This goes well beyond annotations and is essential for safe invocation.

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 somewhat lengthy but logically structured: it opens with the deprecation warning (high priority), then states purpose, usage rules, and finally parameter details. It front-loads the most decision-critical information (deprecation and alternatives) and keeps the rest organized. Minor redundancy with the schema text exists, but it does not detract from readability.

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?

For a mutating task-completion tool with deprecation, permission restrictions, and a validation contract, the description covers all necessary aspects: when to use, when to use alternatives, parameter constraints and side effects, and deprecation status. No critical information is missing for an agent to invoke it 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?

Schema description coverage is 100%, so the baseline is 3. The description adds context beyond the schema: body is the only record future agents have, and output is required/shape-checked under completion_contract. These nuances are valuable even though the schema text largely mirrors the description's parameter explanations.

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 explicitly states the action ('Mark your claimed task as completed') and the condition for invocation ('when the task's expected_outcome has been fully achieved'), and it distinguishes this tool from siblings by naming alternates (task_fail, task_unclaim) for different failure modes. The deprecation note further clarifies its role as legacy functionality, so an agent knows exactly what this tool does and when it is appropriate.

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 provides explicit when-to-use guidance ('when the task's expected_outcome has been fully achieved'), when-not-to-use with named alternatives ('If you cannot finish the task, use task_fail() instead; if you are stepping away mid-work, use task_unclaim()'), and a clear deprecation directive ('not where new work should go'). It also specifies the caller restriction ('Only the claiming agent can complete it'), leaving no ambiguity about invocation context.

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