Complete Task
complete_taskCall this when the work on a task is actually finished — including a task on the user's board that the work you did with them in this conversation finished (search or get_my_work finds it). Never report a task as done to the user without calling it. Pass outcome (1-3 sentences: what was done, where the result lives) and, when you have them, artifacts — anything a person could check without taking your word for it: a URL, a file hash, a message id. This call NEVER fails for missing evidence; finished work is never lost — the receipt is recorded with whatever came in. What the evidence changes is where the task lands: a task marked as needing the user does NOT move to Done, it goes to their queue with your receipt attached, and the answer you give them is "waiting on you", not "done". Everything else finishes and moves to Done by itself. If the task carries a verification plan, the server executes its checks NOW, itself — fetching the URL, looking for the quote, comparing the hash: all blocking checks passing on an executable/state_delta plan verifies the completion; a failed blocking check keeps the task out of Done and returns what the server observed, so fix the work and call this again rather than arguing with the check.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"id": "<id>",
"artifacts": "<artifacts>",
"claims": "<claims>",
"notDone": "<notDone>",
"unknowns": "<unknowns>"
},
"name": "complete_task"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task ID | |
| runId | No | The runId returned by start_task, if you have one | |
| claims | Yes | What you assert you did. Claims, not verdicts — the server does not treat these as verified. | |
| costUsd | No | What this attempt cost, if you know | |
| notDone | Yes | What you did NOT do, said out loud | |
| outcome | No | Short summary of what was done and where the result lives (appended to the task description) | |
| nextStep | No | What you would do NEXT if the user accepts — "merge PR #12 to main", "publish the draft". Only meaningful on work that stops at them: they see this sentence above the Accept button, so accepting approves exactly it. Say what you would actually do, in one line, or leave it out. | |
| unknowns | Yes | What you are unsure about | |
| artifacts | Yes | Evidence a person could check without trusting your account of it. At least one is what separates "done" from "reported done". | |
| learnings | No | Up to 3 lessons worth remembering BEYOND this task — "estimates on frontend tasks run 2x low", "this user rejects copy with exclamation marks". 1–3 sentences each; optionally {trigger, content} where trigger says when to recall it. They surface in every future get_my_work, to every client on this board, and in the planner's own prompt — and nothing here takes one back. Write only what will still be true next month, and nothing about a person you would not put in writing. Not a work log — report progress in `note`/`outcome` instead. | |
| leaseToken | No | The leaseToken returned by start_task |