Skip to main content
Glama

Weft

by com.letsweft
OverviewDiscussionsAdmin

Update Task

update_task
Idempotent

Use this when the user wants to rename, re-prioritize, re-estimate, or otherwise edit an existing task. Only fields you pass are changed; omitted fields stay as-is. The values an edit replaces are kept in the task's journal (get_task_history, mode 'full'), so any edit can be reverted by sending them back. Idempotent. requiresReview can be switched on here; switching it off is the user's, in the Weft app, and a patch that tries to is refused as a whole.

Input Schema

NameRequiredDescriptionDefault
idYes
dueAtNoThe day this is due, as an ISO date-time (only the date part is used, e.g. "2026-10-31T00:00:00Z"). Put a date on anything the user said has a deadline or a day to check back — dated tasks show on the user's Weft calendar and in their subscribed Google/Apple/Outlook calendar. Pass null to clear.
titleNo
projectNoProject name (case-insensitive) or project ID; pass null to detach the task from its project
startAtNoThe day work begins, same format as dueAt. With dueAt it makes a span on the calendar ("measure 5–12 November"); never after dueAt. Pass null to clear.
assigneeNo
priorityNo
blockedByNoREPLACE the set of tasks blocking this one — what you pass is what holds, [] unblocks entirely.
descriptionNo
verificationNoReplace the verification plan (null removes it). Any write resets all check results to pending.
requiresReviewNoStop at the user before this is called done. Set it ONLY for the irreversible: money, publishing outward, production, anything legal. Everything else finishes without them — a queue everything enters is a queue nobody reads. Turning it ON is yours to do; turning it OFF is not. While the flag stands, only the user can take it off — by accepting the finished work in their queue, or in the Weft app themselves. Sending false against a flag that is standing is refused, and the WHOLE call is refused with it: no other field in the same patch is written either. To get flagged work moving, call complete_task — the receipt reaches them with your evidence attached, and their acceptance is what releases the card.
estimateMinutesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / dueAt / description
      Added value: +"The day this is due, as an ISO date-time (only the date part is used, e.g. \"2026-10-31T00:00:00Z\"). Put a date on anything the user said has a deadline or a day to check back — dated tasks show on the user's Weft calendar and in their subscribed Google/Apple/Outlook calendar. Pass null to clear."
    • addedInput schema / properties / startAt
      Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The day work begins, same format as dueAt. With dueAt it makes a span on the calendar (\"measure 5–12 November\"); never after dueAt. Pass null to clear."
+}
  2. Changed1 schema field changed
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
  3. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: explains patch semantics (omitted fields unchanged), that replaced values land in the journal and edits are reversible, that the operation is idempotent, and — most valuably — that a patch attempting to clear requiresReview is refused wholesale so no other field is written. That atomic-failure behavior is not inferable from the schema or annotations.

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?

Front-loads the trigger, then layers patch semantics, reversibility, and the requiresReview exception in descending order of importance. The long requiresReview sentence is dense but carries a constraint an agent would otherwise get wrong; nothing is filler.

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 12-parameter mutation with no output schema, the description covers the two things most likely to cause incorrect calls: partial-patch expectations and the refused-write case. It leaves some gaps — no mention of what a successful response looks like, or how a bad project name or unknown id is reported — but the schema absorbs most field-level detail.

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?

With 12 parameters and only 50% schema description coverage, the description compensates for the highest-risk ones: it establishes the partial-update contract so the agent knows an unset field means "leave alone," and it spends its detail on requiresReview's asymmetric on/off rule. The remaining parameters (dueAt, startAt, assignee, blockedBy, verification) get no description-level meaning, though several carry strong inline schema descriptions.

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 trigger and verb set ("rename, re-prioritize, re-estimate, or otherwise edit an existing task"), which pins this as an in-place edit rather than a create (create_task) or a status/column move (move_task). The field list makes the resource boundary concrete.

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?

Gives an explicit when-to-use condition tied to user intent, and names two adjacent tools in their proper roles (get_task_history for reverting, complete_task for releasing flagged work). It lacks a clear "don't use this for X, use move_task/trash_task instead" exclusion, which is the remaining gap for a full 5.

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

All Weft toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources