Skip to main content
Glama
rtdesignstudio

cemainou

by rtdesignstudio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Update Task Tool

update_task
Idempotent

Modify an existing task by editing its title or details, assigning it, moving it between statuses or projects, ticking checklist steps, and adding comments.

Instructions

Changes a task: edit its title or details (title, notes: the whole new text, read it first with start_task or list_tasks; add_steps appends new - [ ] steps), take it (assignee "me", status "doing"), move it (todo, doing, blocked with a reason, done, dropped; todo turns an idea into a task), move it to another project (move_to_project), remove its files you added (remove_files; to swap a changed file, use add_attachment with replaces instead), give it to someone ("none" frees it), tick its steps (check) or comment on it. Progress on a task with steps is shown by ticking the finished steps (check: [numbers]), not by listing them in a comment; a comment is for questions, answers and what the steps do not cover. Only when the person asked for it.

Input Schema

NameRequiredDescriptionDefault
idYesTask number, e.g. 12.
dueNoA due date, YYYY-MM-DD, or "none" to remove it.
checkNoStep numbers (from 1, as start_task lists them) to tick in the task's checklist, when they are finished.
notesNoThe task's new details (its description), in Markdown: the whole text, replacing the old one. Read the current details first (start_task or list_tasks) and keep what should stay, including the - [ ] / - [x] steps; an empty string clears them. Only when the person asks.
proofNoWith status done: the proof - the commit, the address where the change shows, or a short note. Kept on the task.
titleNoA new title, when the person wants it renamed.
reasonNoWhat a blocked task is waiting for.
repeatNoMakes the task come back: when it is done, the next one is added, due one interval later; "none" stops it.
statusNotodo also turns an idea into a task.
commentNoA comment on the task (a question, a clarification, an answer), in Markdown; colleagues and, on projects visible to the client, the client see it. Not for reporting finished steps: tick them with check (both can go in the same call). Only when the person asks.
uncheckNoStep numbers to untick, if ticked by mistake.
assigneeNo"me", a colleague's name or email, or "none" to free the task.
add_stepsNoNew steps to append to the task's checklist, unticked (just the text of each). Use it instead of notes when only steps are added.
remove_filesNoIds of the task's files to remove (from start_task: those with can_replace). Only the files you added, and only while the task is open: on a closed task they stay as reference. To put a new version in place of a file, use add_attachment with replaces instead.
move_to_projectNoMoves the task, with its files, to another project (slug or name) the person can see. Whoever does it stays on it only if they work on that project too. Only when the person asks.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

The only annotation is idempotentHint, so the description carries the behavioral burden and largely does: it discloses that comments are visible to colleagues and clients, that remove_files only works on files you added and only while the task is open, and that moving projects affects who stays assigned. It does not describe what the call returns or whether partial multi-field updates can fail halfway, which is the remaining gap for a 15-parameter mutation.

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 purpose, and every clause maps to a real capability among 15 parameters, so the length is defensible. The single dense paragraph with heavy parenthetical nesting makes it harder to scan than a short bulleted breakdown would be.

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 a 15-param mutation tool with no output schema, it covers the operation semantics, the ordering prerequisite (read notes first with start_task or list_tasks), and the destructive edge cases. Missing only return/error behavior and any note on multi-field atomicity.

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 coverage is 100%, so baseline is 3. The description adds a little framing (assignee "me" takes the task, status todo promotes an idea) but mostly restates semantics the parameter descriptions already state, such as the "none" sentinels and the check/uncheck step numbering.

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?

Opens with a specific verb and resource ("Changes a task") then enumerates the distinct mutation families it covers: edit, take, move, move project, remove files, assign, tick steps, comment. It distinguishes itself from siblings by name (add_attachment, start_task, list_tasks), so an agent can route without opening the 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?

Gives explicit use-this-not-that routing: add_steps instead of rewriting notes when only steps are added, check instead of a comment for finished steps, add_attachment with replaces instead of remove_files for a swapped file. It also sets the consent condition ("Only when the person asked for it") on the riskiest operations.

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

Deploy Server

Other Tools