Reference

Update tasks in place — one, or several

The update-tasks tool, and the REST call it is generated from.

RESTPATCH /api/v1/tasks/batch

MCPupdate-tasks

The only way to change a task: 1 to 100 items, each an id plus the fields to change, all written or none. Each changes only the fields sent. A status move outside the table answers 409 with from, to and allowed, and nothing lands; an id given twice answers 400. Send basis with the move itself: resending the status a task already has records no change, so a cause left off is given only through reconcile-task. wait: null clears the wait; omitting wait leaves it. Clearing a wait never changes the status: the task then answers get-next?slice=hold_cleared (or date_came) until somebody moves it. Send if_unmodified_since with the updated_at you read to have a concurrent write reported. The answer is one acknowledgement per item, in order.

Body

This operation takes a JSON body. The spec is the contract and it is what the agent reads every turn — seepackages/server/src/rest/openapi/v1/for the shape.

Responses

200Every item was written; one acknowledgement each, in order

400The request body or query string does not match the operation's schema, or a `calendar` task names no date (`calendar_requires_date`)

404No such task

409The status change is not one the GTD state table allows. The body's `error.code` is `invalid_transition` and `error.meta` carries `from`, `to` and `allowed` — the statuses this task can actually move to.

Generated from the spec this operation is implemented against, so the two names above cannot disagree with the surface a client sees.