Skip to main content
Glama

Complete Task

complete_task

Call this when the work on a task is actually finished. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesTask ID
runIdNoThe runId returned by start_task, if you have one
claimsYesWhat you assert you did. Claims, not verdicts — the server does not treat these as verified.
costUsdNoWhat this attempt cost, if you know
notDoneYesWhat you did NOT do, said out loud
outcomeNoShort summary of what was done and where the result lives (appended to the task description)
nextStepNoWhat 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.
unknownsYesWhat you are unsure about
artifactsYesEvidence a person could check without trusting your account of it. At least one is what separates "done" from "reported done".
learningsNoUp 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.
leaseTokenNoThe leaseToken returned by start_task

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description reveals critical behavior: the call never fails for missing evidence, the server executes verification checks immediately, and the outcome placement depends on evidence and verification results. This adds substantial context that annotations do not convey.

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

Conciseness4/5

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

The description is long (about 200 words) but every sentence carries necessary nuance: the key instruction is front-loaded, and later sentences explain verification and queue behavior. It is dense but not wasteful, though it could be tightened slightly.

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 tool with 11 parameters, 5 required, nested artifact objects, and a verification plan, the description covers all critical aspects: when to call, what to pass, how verification works, the distinction between Done and 'waiting on you', and the guarantee that evidence is never lost. No output schema exists, but the description compensates fully.

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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning to `outcome` (1-3 sentences summary) and `artifacts` (evidence a person can check), explaining their role and effect on task placement. It also clarifies the intent of `claims` vs `notDone` implicitly. This exceeds the baseline but does not go into every parameter.

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?

The description explicitly states when to call: 'Call this when the work on a task is actually finished.' It names the resource (task) and the action (complete), and clearly differentiates from siblings like report_progress and request_input by emphasizing that it must be called to mark a task done.

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?

It gives clear when-to-use and when-not-to-use guidance: 'Never report a task as done to the user without calling it.' It also explains the edge case where a task needs user input and does not move to Done but goes to their queue, and that verification failures require re-calling after fixing the work.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources