Casefile

Overview Schema Source Related Servers Discussions Admin

add_verdict

Record the outcome of a review check in the current pass, storing passed or failed verdicts with evidence. Replaces earlier verdicts from this pass and keeps prior passes for reference.

Instructions

Files the outcome of one review check, as run by the task's assignee within the current pass.

A pass starts with each entry into in_progress, a return from waiting included. Only verdicts of the current pass count for closing, and the latest verdict on a check replaces the earlier ones: a failed verdict is filed when it happens, like a passed one. Verdicts of earlier passes stay in the case without counting. close_task also takes verdicts, together with the closing.

Input Schema

TableJSON Schema

Name	Required	Description
`key`	Yes	Task key `PROJECT-N`, case-insensitive; a previous key of a moved task addresses it as well. An unknown key is refused with `task_not_found`
`outcome`	Yes	Outcome of the check; there is no third state
`check_no`	Yes	Number of the review check in the task's list, from 1; a number outside the list is refused with `entry_fields_invalid`
`evidence`	No	What was run for the check as written and what it showed: the command, its output, a link to the material
`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
`no`	Yes	Entry number in the task's case; with the key it forms `TRK-42#12`
`seq`	Yes	Journal sequence number, usable as `after` of `wait_journal`
`title`	Yes	The title the tracker built, for entry types whose title is not sent (summary, answer, verdict, resolution, service entries); `null` when the caller sent the title
`author`	Yes
`task_key`	Yes
`created_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed22 schema fields changedv0.5.2Sep 25, 2026

removedInput schema / $defs

Removed value: -{
-  "VerdictOutcome": {
-    "description": "Исход обзорной проверки. Значений ровно два: третьего состояния у проверки нет.",
-    "enum": [
-      "passed",
-      "failed"
-    ],
-    "title": "VerdictOutcome",
-    "type": "string"
-  }
-}

changedInput schema / properties / check_no / description

Previous value: -"Номер обзорной проверки в списке задачи, с 1"New value: +"Number of the review check in the task's list, from 1; a number outside the list is refused with `entry_fields_invalid`"

removedInput schema / properties / check_no / examples
```
Removed value: -[
-  3
-]
```

changedInput schema / properties / evidence / description

Previous value: -"Доказательство исхода: что запустил, что увидел, ссылка на материал"New value: +"What was run for the check as written and what it showed: the command, its output, a link to the material"

removedInput schema / properties / evidence / examples

Removed value: -[
-  "docker compose run --rm test: 214 passed"
-]

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 / key / description

Previous value: -"Ключ задачи, например `TRK-42`. Регистр не важен"New value: +"Task key `PROJECT-N`, case-insensitive; a previous key of a moved task addresses it as well. An unknown key is refused with `task_not_found`"

removedInput schema / properties / outcome / $ref
```
Removed value: -"#/$defs/VerdictOutcome"
```

changedInput schema / properties / outcome / description

Previous value: -"Исход проверки. Третьего состояния нет"New value: +"Outcome of the check; there is no third state"

addedInput schema / properties / outcome / enum
```
Added value: +[
+  "passed",
+  "failed"
+]
```
removedInput schema / properties / outcome / examples
```
Removed value: -[
-  "passed"
-]
```
addedInput schema / properties / outcome / type
```
Added value: +"string"
```

removedOutput schema / $defs / AuthorKind

Removed value: -{
-  "description": "Кто именно сделал действие.\n\n`tracker` — сам трекер: этим родом подписаны служебные записи дела и строки,\nзаведённые командой первичной инициализации. У него нет подписи, потому что\nназывать себя по имени ему незачем: трекер в установке один.",
-  "enum": [
-    "agent",
-    "human",
-    "tracker"
-  ],
-  "title": "AuthorKind",
-  "type": "string"
-}

changedOutput schema / $defs / AuthorView / description

Previous value: -"Кто сделал действие: род и подпись. У самого трекера подписи нет."New value: +"Who acted: kind and signature. The tracker itself has no signature."

removedOutput schema / $defs / AuthorView / properties / kind / $ref
```
Removed value: -"#/$defs/AuthorKind"
```

addedOutput schema / $defs / AuthorView / properties / kind / description

Added value: +"Kind of author. `tracker` signs the service entries the tracker files itself"

addedOutput schema / $defs / AuthorView / properties / kind / enum
```
Added value: +[
+  "agent",
+  "human",
+  "tracker"
+]
```
addedOutput schema / $defs / AuthorView / properties / kind / type
```
Added value: +"string"
```

changedOutput schema / description

Previous value: -"Ответ подшивающего инструмента: чем запись адресуют, без самой записи.\n\n`title` непуст только там, где заголовок собрал трекер: у сводки, ответа, вердикта и\nрезолюции его не принимают вовсе (`app/domain/case.py`, `TITLED_ENTRY_TYPES`). Где\nзаголовок прислал агент, здесь стоит `null` — «в описи ровно то, что ты прислал»."New value: +"A filed entry, by its address rather than its content; the entry in full is\nreturned by `read_entries`."

addedOutput schema / properties / no / description

Added value: +"Entry number in the task's case; with the key it forms `TRK-42#12`"

addedOutput schema / properties / seq / description

Added value: +"Journal sequence number, usable as `after` of `wait_journal`"

addedOutput schema / properties / title / description

Added value: +"The title the tracker built, for entry types whose title is not sent (summary, answer, verdict, resolution, service entries); `null` when the caller sent the title"

First observedSep 23, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only say this is not read-only/idempotent, so the description carries the behavioral burden. It discloses that the latest verdict replaces earlier ones, that failed verdicts are filed immediately like passed ones, and that earlier-pass verdicts persist without counting. That is substantive stateful behavior beyond what annotations or schema indicate.

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?

The purpose sentence is front-loaded and the second paragraph earns its place by explaining pass-scoping, replacement, and the close_task overlap. There is no filler or repetition of schema content.

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?

Between the schema (parameters, errors, idempotency) and the description (pass semantics, replacement, close_task overlap), an agent has what it needs to call add_verdict correctly. The main gap is that prerequisites such as assignee permission are implied rather than stated, and the return shape is left to the output schema.

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?

All five parameters are already fully described in the schema (100% coverage), including enums, defaults, errors, and idempotency semantics. The description adds lifecycle context but no additional parameter-level meaning, so the baseline of 3 is appropriate.

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 opening sentence names a specific verb ('Files'), a resource ('outcome of one review check'), and a scope ('as run by the task's assignee within the current pass'). The closing note that close_task also takes verdicts helps an agent distinguish this tool from the sibling that handles verdicts during closing.

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 gives the operative context: verdicts only count if filed in the current pass, and earlier-pass verdicts remain but do not count. It also points to close_task as the sibling that takes verdicts together with closing, which implies the alternative. It stops short of an explicit 'use X instead when...' rule, so not a 5.

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