Skip to main content
Glama

Onplana

by io.github.Onplana
OverviewDiscussionsAdmin

update_task

DestructiveIdempotent

Partially update one task. Pass only the fields you want to change: title (string, 1-500 chars), description (string or null to clear, up to 10000 chars), status (TODO/IN_PROGRESS/REVIEW/DONE/BLOCKED), priority (LOW/MEDIUM/HIGH/CRITICAL, a ranking label that does not put a task on the critical path), dueDate (ISO or null to clear), startDate (ISO or null), assigneeId (user id or null to unassign), progress (0-100), estimatedHours (number or null to clear), agentBrief (per-task agent spec, string or null to clear), isMilestone (boolean), constraintType (ASAP/ALAP/MSO/MFO/SNET/SNLT/FNET/FNLT or null) + constraintDate + deadline (ISO dates or null), plannedCost + fixedCost + baselineCost (currency numbers or null), recurringRule ({freq,interval,endDate?} object or null), previewUrl + prUrl (URLs or null to clear), isManual (for a task with subtasks: true keeps its own dates, false takes them from its subtasks, null follows the project). A date, duration or constraint change on a task whose dates come from its subtasks is refused with code:"PARENT_DATES_FROM_SUBTASKS"; change a subtask, or send isManual:true with the dates. Optional notify="owner"|"assigner"|"both" sends a notification to the assignee, the creator, or both. Optional reason adds a comment with the supplied text and includes it in the notification body. Caller must have task.edit.any on the project, or task.edit.own + ownership. Optional expectedUpdateRevision guards against overwriting a concurrent edit: when it no longer matches, the call SUCCEEDS with applied:false and code:"UPDATE_REVISION_MISMATCH" and writes nothing, so read applied before treating the task as changed. A real write returns applied:true. In a project with automatic scheduling off, a date or duration change moves no other task, and the result carries autoScheduleOff:true. When the edit moves the project finish, the result carries finishMove: the old and new finish, what changed, the driving chain, and plain sentences. PREFER bulk_update_status when flipping status on 2+ tasks at once; PREFER bulk_update_tasks when applying the SAME multi-field patch to 2+ tasks.

Input Schema

NameRequiredDescriptionDefault
prUrlNoSource-control PR URL, or null to clear.
titleNoNew title (1-500 chars).
dryRunNoPreview only. Return the per-field diff (current vs proposed) + currentUpdateRevision without committing. Writes nothing and fires no side effects. Pair with expectedUpdateRevision on the real call.
notifyNoSend a notification to owner (assignee), assigner (creator), or both.
reasonNoFree-text reason for the update, up to 5000 chars. Adds a comment + appears in the notification body.
statusNo
taskIdYesTask to update.
dueDateNoISO date or null to clear.
noCacheNoBypass idempotency dedup for this call (re-runs apply on a byte-identical retry). Use only when a prior write was confirmed lost; prefer expectedUpdateRevision.
deadlineNoHard deadline (distinct from dueDate target); ISO date or null to clear.
isManualNoFor a task with subtasks: true keeps its own dates, false takes its start and due from its subtasks, null follows the project.
parentIdNoMove task to a different parent. Pass null to move to project root.
priorityNoPriority label (LOW/MEDIUM/HIGH/CRITICAL) that people set to rank work. It is not the critical path: the schedule engine computes that from dependencies, durations and the calendar, and priority does not change it.
progressNoInteger 0-100.
fixedCostNoFixed cost (currency, 2dp), or null to clear.
startDateNoISO date or null to clear.
agentBriefNoPer-task agent spec/brief, or null to clear. Up to 20000 chars.
assigneeIdNoUser id or null to unassign.
previewUrlNoDeployed preview URL, or null to clear.
actualStartNoISO date work actually began. Stamped automatically from startDate the first time the task leaves TODO or gains progress. Changing it on a task that is not DONE and not pinned by MSO or MFO moves startDate to it and dueDate to where the remaining work finishes; sending dates too lets the dates win. null clears.
descriptionNoNew description, or null to clear.
isMilestoneNoFlip the task into (true) or out of (false) milestone mode.
plannedCostNoPlanned cost (currency, 2dp), or null to clear.
baselineCostNoBaseline/original-budget cost (currency, 2dp), or null to clear.
recurringRuleNoRecurring config { freq: daily|weekly|monthly, interval: int>=1, endDate?: ISO|null }, or null to stop recurring.
constraintDateNoISO date for the constraint, or null to clear.
constraintTypeNoMS Project constraint: ASAP/ALAP (as soon/late as possible), MSO/MFO (must start/finish on), SNET/FNET (start/finish no earlier than), SNLT/FNLT (start/finish no later than), or null to clear.
estimatedHoursNoEstimated hours of effort; null to clear; matches create_task contract.
expectedUpdateRevisionNo§U3 optimistic-concurrency guard. Pass Task.updateRevision from your last read; mismatch returns UPDATE_REVISION_MISMATCH so concurrent agents don't silently overwrite each other.
originalDurationMinutesNoPlanned duration in working minutes (a day is the project calendar's hoursPerDay, default 8h = 480). Setting it on a task with a startDate moves dueDate to match; sending dates too lets the dates win. null clears.
remainingDurationMinutesNoWorking minutes left. Defaults to original x (1 - progress); DONE forces 0. On a started task (actualStart set) that is not DONE and not pinned by MSO or MFO, changing it moves dueDate to where that work finishes, counted from the later of actualStart and the project status date; sending dates too lets the dates win. null clears.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / actualStart
      Added value: +{
+  "description": "ISO date work actually began. Stamped automatically from startDate the first time the task leaves TODO or gains progress. Changing it on a task that is not DONE and not pinned by MSO or MFO moves startDate to it and dueDate to where the remaining work finishes; sending dates too lets the dates win. null clears.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • changedInput schema / properties / constraintType / description
      Previous value: -"MS Project constraint: ASAP / SNET / FNLT / MSO, or null to clear."New value: +"MS Project constraint: ASAP/ALAP (as soon/late as possible), MSO/MFO (must start/finish on), SNET/FNET (start/finish no earlier than), SNLT/FNLT (start/finish no later than), or null to clear."
    • changedInput schema / properties / constraintType / enum
      Previous value: -[
-  "ASAP",
-  "SNET",
-  "FNLT",
-  "MSO",
-  null
-]New value: +[
+  "ASAP",
+  "ALAP",
+  "MSO",
+  "MFO",
+  "SNET",
+  "SNLT",
+  "FNET",
+  "FNLT",
+  null
+]
    • addedInput schema / properties / isManual
      Added value: +{
+  "description": "For a task with subtasks: true keeps its own dates, false takes its start and due from its subtasks, null follows the project.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}
    • addedInput schema / properties / originalDurationMinutes
      Added value: +{
+  "description": "Planned duration in working minutes (a day is the project calendar's hoursPerDay, default 8h = 480). Setting it on a task with a startDate moves dueDate to match; sending dates too lets the dates win. null clears.",
+  "minimum": 0,
+  "type": [
+    "integer",
+    "null"
+  ]
+}
    • addedInput schema / properties / priority / description
      Added value: +"Priority label (LOW/MEDIUM/HIGH/CRITICAL) that people set to rank work. It is not the critical path: the schedule engine computes that from dependencies, durations and the calendar, and priority does not change it."
    • changedInput schema / properties / reason / description
      Previous value: -"Free-text reason for the update. Adds a comment + appears in the notification body."New value: +"Free-text reason for the update, up to 5000 chars. Adds a comment + appears in the notification body."
    • addedInput schema / properties / remainingDurationMinutes
      Added value: +{
+  "description": "Working minutes left. Defaults to original x (1 - progress); DONE forces 0. On a started task (actualStart set) that is not DONE and not pinned by MSO or MFO, changing it moves dueDate to where that work finishes, counted from the later of actualStart and the project status date; sending dates too lets the dates win. null clears.",
+  "minimum": 0,
+  "type": [
+    "integer",
+    "null"
+  ]
+}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Far exceeds annotations: discloses the PARENT_DATES_FROM_SUBTASKS refusal, the expectedUpdateRevision concurrency guard and its applied:false/UPDATE_REVISION_MISMATCH semantics, notification behavior for notify/reason, the autoScheduleOff result flag, and the finishMove return payload. The destructive/idempotent hints are consistent and the description adds substantial context the annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and the routing advice, but the middle is a long run-on enumeration of all 31 fields that duplicates the schema nearly verbatim, inflating length without adding value. The genuinely novel behavioral content is buried inside that enumeration rather than separated out.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 31-parameter destructive mutation with no output schema, the description covers permissions, concurrency guard, error codes, notification side effects, scheduling side effects, and the shape of the result (applied, autoScheduleOff, finishMove). An agent has everything needed to call it correctly and interpret the outcome.

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 description coverage is 97%, so the schema already documents the 31 parameters well; a baseline of 3 applies. The description largely restates schema field wording (ranges, enum values, priority-as-label explanation) with little new per-parameter meaning, though grouping the fields is mildly helpful.

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 + resource + scope: 'Partially update one task', immediately signalling a single-task PATCH-style edit rather than a create or bulk operation. It names the sibling tools it is NOT and the conditions that select them, so the agent can distinguish update_task from bulk_update_status and bulk_update_tasks without reading schemas.

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?

Explicit guidance on the update contract ('Pass only the fields you want to change') plus explicit routing rules: 'PREFER bulk_update_status when flipping status on 2+ tasks' and 'PREFER bulk_update_tasks when applying the SAME multi-field patch to 2+ tasks'. It also states the precondition (task.edit.any on the project, or task.edit.own + ownership). Nothing is left to inference.

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

All Onplana 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