Skip to main content
Glama
Cafelatte1

FronyBoard

update_task

Edit a task's title, note, branch, tags, dependencies, or completion proof without changing its status. Omit fields to keep them unchanged; pass empty values to clear optional fields.

Instructions

Use it when a task's title, note, branch, tags or links change (edit a task).

Update a task's fields — everything except status, which is transition_task.
`branch` records the working branch name; `content` replaces the one-line note
(same rule as create_task: one line, at most 300 characters). `check` corrects the
proof recorded at completion and is only accepted on a task that is already done.

`tags` replaces the whole label list — pass the tags the task should end up with,
not just the new ones. `depends_on` likewise replaces the whole predecessor list.

Omitted fields are left as they are. To remove an optional field pass an empty value:
`content=""`, `branch=""`, `tags=[]`, `depends_on=[]`, `check=""` (title cannot be removed).

`task_id` is the full id including the project prefix, e.g. DLY-042 — the project
is derived from that prefix, so `key` may be omitted (if given it must match).

Input Schema

NameRequiredDescriptionDefault
keyNo
tagsNo
checkNo
titleNo
branchNo
contentNo
task_idYes
depends_onNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: list fields replace wholesale rather than append, omitted fields are preserved, empty values remove optional fields, title cannot be removed, and `check` is only accepted on an already-done task. These are exactly the mutation semantics that cause silent data loss if unknown.

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?

Front-loaded with the trigger and the scope exclusion in the first two lines, then grouped by concern (replace semantics, empty-value removal, id format). Slightly long and repeats the create_task content rule, but every sentence carries information an agent needs to avoid corrupting data.

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?

For an eight-parameter mutation tool with no annotations and no output schema, this covers inputs thoroughly. The remaining gap is the return side – it never says whether the call returns the updated task or how failures (unknown id, mismatched key, check on an unfinished task) surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates for all eight parameters: branch, content (with length/one-line constraint), check, tags, depends_on, title, and both task_id/key including the DLY-042 prefix format and the derive-project-from-prefix rule that makes `key` optional.

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 (update) and resource (a task's fields) and immediately scopes it: 'everything except status, which is transition_task.' An agent can distinguish this from transition_task and create_task without opening any schema.

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?

Opens with an explicit trigger ('Use it when a task's title, note, branch, tags or links change') and names the excluded case with the correct alternative (status goes to transition_task). It also defers to create_task for the shared one-line/300-char content rule, giving an implicit routing map.

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