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

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. Changed1 schema field changed
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=true; the description adds substantial non-obvious behavior: the call never fails for missing evidence, evidence is recorded regardless, needs-user tasks are routed to a queue rather than Done, and the server executes verification-plan checks server-side and blocking failures keep the task out of Done. This is exactly the kind of behavioral context 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.

Conciseness4/5

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

The most important instruction (when to call) is front-loaded and every sentence carries information. It is a dense single block with some long compound sentences, so structure could be improved, but there is little waste.

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 mutation tool with 11 params and no output schema, the description covers the safety/routing model, the evidence model, the verification-check execution, and the failure semantics. An agent has everything it needs to call correctly and to interpret the outcome.

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, but the description goes beyond the schema by defining how key params behave: outcome as 1-3 sentences of what was done and where the result lives, artifacts as independently checkable evidence, and nextStep as the sentence shown above the user's Accept button. It adds real meaning over the structured field descriptions.

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 states a specific verb and resource ('work on a task is actually finished', task moves to Done) and distinguishes the terminal state-change from sibling operations like report_progress and request_input by naming the routing consequences. An agent can tell this is the completion call without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ('Call this when the work on a task is actually finished') plus a hard prohibition ('Never report a task as done to the user without calling it') and an implicit when-not ('report progress in note/outcome instead'). It stops short of naming sibling tools like report_progress or request_input as the alternative for non-finished 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.