Casefile

by azimov777

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

create_task

Create a task in the backlog, optionally under a parent, with project key, title, and description to track work.

Instructions

Creates a task in backlog; a new task starts in no other status.

With parent, the task is born as the parent's child in the same call: the link files link_added both in the new task's case and in the parent's case, and parent_entry in the response is the number of the parent's entry.

A child task takes a part of the parent's work when the parent's output falls into separate results, its checks cannot all pass in one pass, the work does not fit one pass, or it depends on something that does not exist yet. These signs appear on entry into the parent and after each attempt.

The response carries the key issued by the tracker. An empty title or description is refused with task_fields_invalid.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`title`	Yes	Task title, one line
`parent`	No	Key of the parent task: the new task is born as its child. A closed parent is refused with `task_closed`. The parent is not closed — neither `done` nor `cancelled` — while any of its children is open
`project`	Yes	Project key, case-insensitive. An unknown key is refused with `project_not_found`
`assignee`	No	Participant name or temporary agent label. The tracker never sets or clears it by itself; only a caller whose signature matches it moves the task into `in_progress`
`priority`	No	Task priority	normal
`sections`	No	The five sections. The task moves from `backlog` to `open` only with four non-empty text sections and at least one check (`task_sections_incomplete` otherwise); until then they can be completed with `update_task`
`description`	Yes	What happened and why it is a task. For a continuation of a closed task it names the task the work grew from; the lineage itself is a `relates` link
`idempotency_key`	No	Retry key chosen by the caller, e.g. a UUID. A repeat with the same key and the same arguments returns the first result and creates nothing; the same key with other arguments is refused with `idempotency_key_reused`. A key is bound to the caller's token and kept for 24 hours

Output Schema

TableJSON Schema

Name	Required	Description
`key`	Yes
`status`	Yes	Task status
`entries`	Yes	Numbers of the entries filed in this task's case, in filing order. Empty when the sent values were already in place; the version then stays the same
`version`	Yes	Task version after the call
`parent_entry`	No	Number of the `link_added` entry filed into the parent task's own case when `create_task` was given `parent`. `null` when no `parent` was given, and always `null` for `transition` and `update_task`: they touch no other task's case.

Schema Changelog

Changes observed during successful MCP inspections.

Changed34 schema fields changedv0.5.2Sep 25, 2026

removedInput schema / $defs / TaskPriority

Removed value: -{
-  "description": "Приоритет. Порядок членов — от низшего к высшему, на него опирается сортировка поиска.",
-  "enum": [
-    "low",
-    "normal",
-    "high",
-    "critical"
-  ],
-  "title": "TaskPriority",
-  "type": "string"
-}

changedInput schema / $defs / TaskSections / description

Previous value: -"Пять разделов задачи. Правятся только в `backlog`, дальше неизменяемы."New value: +"The five task sections; they are editable only while the task is in `backlog`."

changedInput schema / $defs / TaskSections / properties / checks / description

Previous value: -"Обзорные проверки по порядку, нумерация с 1: что запустить и что должно получиться"New value: +"Review checks in order, numbered from 1; each names what is run and the expected result"

removedInput schema / $defs / TaskSections / properties / checks / examples

Removed value: -[
-  [
-    "docker compose run --rm test: весь набор зелёный"
-  ]
-]

changedInput schema / $defs / TaskSections / properties / constraints / description

Previous value: -"Чего не делать, что не входит, чего нельзя менять"New value: +"What is out of scope and what stays unchanged"

changedInput schema / $defs / TaskSections / properties / context / description

Previous value: -"Что уже есть, на что опираться, какие заметки читать"New value: +"What already exists and what the work relies on"

changedInput schema / $defs / TaskSections / properties / goal / description

Previous value: -"Зачем задача нужна и что изменится"New value: +"Why the task exists and what will change"

changedInput schema / $defs / TaskSections / properties / output / description

Previous value: -"Что должно существовать по завершении"New value: +"What exists once the task is done"

changedInput schema / properties / assignee / description

Previous value: -"Имя участника или метка временного агента. Трекер сам его не ставит и не снимает; в `in_progress` задачу переводит только тот, чья подпись с ним совпадает"New value: +"Participant name or temporary agent label. The tracker never sets or clears it by itself; only a caller whose signature matches it moves the task into `in_progress`"

removedInput schema / properties / assignee / examples
```
Removed value: -[
-  "release_bot"
-]
```

changedInput schema / properties / description / description

Previous value: -"Описание задачи: что случилось и почему это задача"New value: +"What happened and why it is a task. For a continuation of a closed task it names the task the work grew from; the lineage itself is a `relates` link"

removedInput schema / properties / description / examples

Removed value: -[
-  "Ключ выдаётся до валидации и сгорает на неудачном запросе"
-]

changedInput schema / properties / idempotency_key / description

Previous value: -"Ключ повтора, который ты придумываешь сам (обычно UUID). Повтор вызова с тем же ключом и теми же аргументами отвечает первым результатом и второго объекта не заводит; тот же ключ с другими аргументами отклоняется. Ключ живёт в паре с твоим токеном и помнится 24 часа"New value: +"Retry key chosen by the caller, e.g. a UUID. A repeat with the same key and the same arguments returns the first result and creates nothing; the same key with other arguments is refused with `idempotency_key_reused`. A key is bound to the caller's token and kept for 24 hours"

changedInput schema / properties / parent / description

Previous value: -"Ключ родительской задачи. Ребёнок рождается со ссылкой на родителя; родитель не закроется — ни в `done`, ни в `cancelled`, — пока дети не закрыты. Закрытую задачу родителем назначить нельзя"New value: +"Key of the parent task: the new task is born as its child. A closed parent is refused with `task_closed`. The parent is not closed — neither `done` nor `cancelled` — while any of its children is open"

removedInput schema / properties / priority / $ref
```
Removed value: -"#/$defs/TaskPriority"
```

changedInput schema / properties / priority / description

Previous value: -"Приоритет задачи"New value: +"Task priority"

addedInput schema / properties / priority / enum

Added value: +[
+  "low",
+  "normal",
+  "high",
+  "critical"
+]

removedInput schema / properties / priority / examples
```
Removed value: -[
-  "normal"
-]
```
addedInput schema / properties / priority / type
```
Added value: +"string"
```

addedInput schema / properties / project

Added value: +{
+  "description": "Project key, case-insensitive. An unknown key is refused with `project_not_found`",
+  "examples": [
+    "TRK"
+  ],
+  "title": "Project",
+  "type": "string"
+}

removedInput schema / properties / queue

Removed value: -{
-  "description": "Ключ очереди, например `TRK`. Регистр не важен",
-  "examples": [
-    "TRK"
-  ],
-  "title": "Queue",
-  "type": "string"
-}

changedInput schema / properties / sections / description

Previous value: -"Пять разделов задачи. Без четырёх непустых разделов и хотя бы одной проверки задача не откроется; дописать их можно, пока она в `backlog`"New value: +"The five sections. The task moves from `backlog` to `open` only with four non-empty text sections and at least one check (`task_sections_incomplete` otherwise); until then they can be completed with `update_task`"

changedInput schema / properties / title / description

Previous value: -"Название задачи одной строкой"New value: +"Task title, one line"

removedInput schema / properties / title / examples

Removed value: -[
-  "Починить выдачу ключей задач"
-]

changedInput schema / required

Previous value: -[
-  "queue",
-  "title",
-  "description"
-]New value: +[
+  "project",
+  "title",
+  "description"
+]

removedOutput schema / $defs

Removed value: -{
-  "TaskStatus": {
-    "description": "Зашитый список статусов (`CONCEPT.md`, 3.3).",
-    "enum": [
-      "backlog",
-      "open",
-      "in_progress",
-      "waiting",
-      "done",
-      "cancelled"
-    ],
-    "title": "TaskStatus",
-    "type": "string"
-  }
-}

changedOutput schema / description

Previous value: -"Ответ изменяющего инструмента: что стало и чем это подшито, без карточки."New value: +"Task state after the call and the entries it filed; the card in full is returned\nby `get_task`."

addedOutput schema / properties / entries / description

Added value: +"Numbers of the entries filed in this task's case, in filing order. Empty when the sent values were already in place; the version then stays the same"

addedOutput schema / properties / parent_entry

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Number of the `link_added` entry filed into the parent task's own case when `create_task` was given `parent`. `null` when no `parent` was given, and always `null` for `transition` and `update_task`: they touch no other task's case.",
+  "title": "Parent Entry"
+}

removedOutput schema / properties / status / $ref
```
Removed value: -"#/$defs/TaskStatus"
```
addedOutput schema / properties / status / description
```
Added value: +"Task status"
```

addedOutput schema / properties / status / enum

Added value: +[
+  "backlog",
+  "open",
+  "in_progress",
+  "waiting",
+  "done",
+  "cancelled"
+]

addedOutput schema / properties / status / type
```
Added value: +"string"
```
addedOutput schema / properties / version / description
```
Added value: +"Task version after the call"
```

First observedSep 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations provide no safety hints (readOnly=false, idempotent=false), so the description bears full responsibility for behavioral disclosure. It clearly states the new task's status, the parent-child linking effect (files `link_added`), and the response containing the key. It also mentions the `task_fields_invalid` error for empty title/description. However, it does not cover idempotency behavior or retention of keys, which the schema documents but the description omits. For a mutating create operation, this is reasonable coverage but not exhaustive.

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 structured into four paragraphs, each serving a distinct purpose: initial status, parent behavior, child-task rationale, and response/error. It is not overly verbose, but the third paragraph on when child tasks are appropriate is quite detailed and somewhat tangential to the core creation task. Overall, each sentence contributes useful information, though it could be tightened slightly.

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?

The tool has 8 parameters (3 required) and an output schema, so the description need not restate return values. It covers the essential behavioral context: default status, parent-link behavior, and an error condition. It does not explain the `sections` parameter's role in transitioning to `open` (though the schema covers this), nor does it mention idempotency. Given the complexity, the description is mostly complete for an agent to correctly invoke the tool, with minor gaps filled by the schema.

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%, establishing a baseline of 3. The description adds meaningful semantics beyond the schema by elaborating on the `parent` parameter's behavioral implications (the link event, the parent_entry in response, and the rationale for child tasks). It also highlights that an empty title or description triggers a specific error, which relates to the required parameters. This extra context raises the score to 4.

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 an explicit verb and resource ('Creates a task') and immediately states the initial status ('in `backlog`; a new task starts in no other status'). It clearly distinguishes from siblings like update_task, transition, and close_task by focusing on creation semantics. The specific scope (project, parent, sections) is also hinted, making the purpose unambiguous.

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?

The description implicitly signals when to create a task (to start work in backlog) and provides detailed guidance on using the `parent` parameter to create child tasks under specific conditions. It does not explicitly name alternatives like update_task for modifications, but the creation purpose is so obvious that an agent can infer appropriate usage. The explanation of when child tasks are appropriate adds context, though it lacks explicit 'when-not-to-use' statements.

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