Reference

Create or resolve tasks — one, or several linked to each other

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

RESTPOST /api/v1/tasks/batch

MCPupsert-tasks

The only way to create a task: 1 to 100 items, all written or none. project, status and title are the whole of a capture. The answer is one acknowledgement per item, in order, beside its ref; get-task reads the whole task. A `dedupe_on` hit resolves, it never rewrites: the task stays as it was (resolved: true, ignored naming what it did not write); references, links and wait still attach. Change its fields with update-tasks. Refused, rolling back every item: a calendar item with no date (400), a dedupe_on hit moving a closed task (409), a duplicate ref or a link to a ref no item carries (400). The rest lands and is reported: a blocks cycle is stored, a task that blocks itself is flagged, a { "title" } end comes back under unresolved.

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 or resolved; one acknowledgement each, in the order sent

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.