Skip to main content
Glama

update_task

Modify an existing task by changing any of its fields: title, description, dates, priority, progress, or completion state. Pass only fields to change; mark done to open or close the task.

Instructions

Update a task. Only the fields you pass change. Use done to open/close it.

v1 has no partial update. There, this reads the task and writes it back with your changes merged in, at the cost of one extra request. v2 is a single PATCH unless a description is involved.

due_date is the deadline. start_date and end_date are ISO 8601 datetimes marking the window you plan to work on the task (start work / finish work). Pass an empty string to any of the three to clear it.

percent_done is a fraction despite the name. A quarter done is 0.25. Vikunja does not validate it, and 50 is stored as 50.

repeat_after is a number of seconds. Setting it changes what done means for this task: it reopens itself with its dates moved forward. repeat_mode is 0 to advance by repeat_after, 1 to repeat monthly and ignore repeat_after, or 2 to count from the day it was completed. A repeating task with no dates can never be closed: it reopens regardless.

Two wrinkles in what comes back. On v2 a partial update returns the description as the stored HTML. v2 does not convert on a PATCH. Call get_task when you need it as Markdown. And a write that changes nothing returns {"ok": true, "unchanged": true} there, which is Vikunja answering 304.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
doneNo
titleNo
task_idYes
due_dateNo
end_dateNo
priorityNo
start_dateNo
descriptionNo
is_favoriteNo
repeat_modeNo
percent_doneNo
repeat_afterNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.2.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries full burden. It thoroughly discloses partial-update behavior, v1/v2 differences, field semantics (percent_done is a fraction, repeat modes), response quirks (HTML vs Markdown, 304 unchanged), and validation gaps (Vikunja doesn't validate percent_done). This is exceptionally transparent.

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 long but every sentence carries substantive information. It is front-loaded with the core action and then systematically covers field semantics and edge cases. The structure is logical (partial update, dates, percentages, repeats, response quirks) without redundancy.

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?

Given the tool's complexity (12 params, 0% schema coverage, no output schema), the description is quite complete. It covers the tricky fields and response nuances but omits some self-explanatory params (title, priority, is_favorite) and does not mention error cases. However, the main risks are well addressed.

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%, so the description must compensate. It explains due_date, start_date/end_date (ISO 8601, clear via empty string), percent_done (fraction, not percent), repeat_after (seconds) and repeat_mode (0/1/2 meanings). Also covers the done parameter's interaction with repeat. This adds critical meaning beyond the raw schema.

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 and resource ('Update a task') and immediately clarifies the partial-update semantics. It differentiates behavior across v1/v2 and explains field-specific effects, making the tool's scope unambiguous even without naming sibling tools.

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?

Provides clear context for when to call get_task ('when you need it as Markdown') and explains v1 vs v2 behavior that affects usage (extra request vs PATCH). Does not explicitly mention alternatives like bulk_update_tasks, but the guidance is sufficient for common usage decisions.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aichholzer/altiplano'

If you have feedback or need assistance with the MCP directory API, please join our Discord server