Skip to main content
Glama

Complete Task

complete_task
Idempotent

Mark task as ready for review (in_review). A human will verify and move it to done. Pass skipReview: true to mark as done immediately (use when the human explicitly asks).

If the task is already in_review (put there by a previous complete_task call), calling this again will move it directly to done — no checklist required (already confirmed). Tasks put in review with request_review are the exception: wait for the reviewer, then resume with start_task.

Self-assessment (required): Pass selfAssessment reflecting on your session — what project knowledge was missing, what tools were confusing, what process gaps caused friction. Pass empty object {} if nothing to report. For non-trivial code work, include at least one concrete entry instead of an all-empty assessment. Also pass model and reasoningEffort when known; top-level values override nested selfAssessment metadata. You can also call review_task separately before this, but passing selfAssessment here is simpler.

Before calling:

  1. Push all commits and open a pull request for the change — the PR is the primary deliverable

  2. Link the PR with link_pr, or pass it here via the pr parameter

  3. Check if project context docs need updating

Completion checklist: If the project has a completion checklist (shown in start_task response), load relevant branches with get_completion_checklist, then resolve each active item by itemId. Use status: "done" with structured proof, or status: "skipped" for not-applicable items. If the checklist uses scope dimensions, pass checklistScope with explicit appliesTo, changeKinds, and riskDomains as needed. If a task crosses surfaces or contracts, bias toward broader scope rather than narrower scope.

Pull request: Pass pr ({url, branch?, title?, state?}) if the PR is not yet linked. Commits are a secondary detail; the linked PR is what reviewers look at.

Delegations: If you delegated work to sub-agents during this session, report them via delegations ([{agent, model?, description?}]).

Commits: Pass commits array to log them at completion (convenience for final commits).

Completion receipt: Pass outcome (defaults to summary), deliveredScope (defaults to titles of done subtasks), and residualRisks to build the compact completion receipt shown by get_task. This is what future agents and reviewers see instead of re-reading the full history.

Review instructions: When sending to review (default), provide reviewInstructions — specific steps for the reviewer: what to test in UI, edge cases, areas of risk. Not a restatement of what was done. These are PUBLICLY VISIBLE on the roadmap while the item is in review, so write them for an external reader and keep credentials, internal paths, and private URLs out of them.

Review evidence: When the change scope (declared checklistScope, scope inferred from touchedPaths, and what prepare_completion recorded) matches the project policy — contract_changes → API examples (add_api_example), rendering_changes / public_output_changes → screenshots (add_screenshot), and diagrams (add_diagram) when the project requires them — the evidence must be attached first. Missing suggested evidence comes back as evidenceWarnings; missing required evidence blocks the hand-off (error code review_evidence_missing listing each missing kind and the change kinds/surfaces that need it) unless you pass evidenceNotApplicable with the reason. After a review round, only artifacts attached since the reviewer's decision count. prepare_completion reports what is missing ahead of time.

Preview: pass previewUrl when the change is running somewhere the reviewer can open (e.g. a Tailscale URL); internal only, never public.

Waiting: when the task lands in in_review, the response tells you how to wait with damper review wait <taskId> (exit 10 = needs work, 0 = approved, 2 = timed out, 1 = error) if your Damper CLI is 0.13.0 or newer (damper --version); with an older CLI, poll get_task.

Returns documentation update suggestions.

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": {
      "projectId": "<projectId>",
      "taskId": "<taskId>",
      "summary": "<summary>"
    },
    "name": "complete_task"
  }
}

Input Schema

NameRequiredDescriptionDefault
prNoPull request delivering this task, if not already linked via link_pr. Upserts by URL.
modelNoModel identifier used for this task/session, e.g. claude-opus-4.8 or gpt-5.5. Overrides selfAssessment.model.
taskIdYes
commitsNoOptional: commits to log at completion
outcomeNoOne-line outcome for the completion receipt (defaults to `summary`).
summaryYesBrief one-line summary of what was done, written for end users. Focus on the outcome, not the implementation.
projectIdYesProject ID. Use list_projects to find available project IDs.
previewUrlNoOptional http(s) URL where the reviewer can open the running change, e.g. a Tailscale URL like http://laptop.tailnet.ts.net:5173. Private hosts are fine (it is never fetched by the server). INTERNAL: shown only to reviewers in the dashboard, never on public roadmaps. Pass null to clear.
skipReviewNoSkip human review and mark task as done immediately (default: false, task goes to in_review)
delegationsNoSub-agent delegations that happened during this session
touchedPathsNoRepository-relative paths changed by the task. Git-aware clients should derive this list automatically when possible.
confirmationsNoCompletion checklist resolutions — resolve each active item by `itemId` with structured proof
residualRisksNoKnown residual risks or follow-ups left after this completion, for the completion receipt.
checklistScopeNoRequired when the checklist uses scoped appliesTo / when / riskDomains rules
deliveredScopeNoWhat was delivered, for the completion receipt (defaults to titles of done subtasks, else empty).
selfAssessmentNoSelf-review of your session. Object with optional keys: missingContext (string[]), toolIssues (string[]), processGaps (string[]), model, reasoningEffort. Reflect on what went well, what knowledge was missing, what caused friction. Pass {} if nothing to report.
reasoningEffortNoReasoning effort used for this task/session, e.g. low, medium, high. Overrides selfAssessment.reasoningEffort.
contextDispositionNoExplicit disposition of context impact: updated, verified_current, not_applicable, or deferred.
reviewInstructionsNoWhat the reviewer should test or verify (markdown). Recommended when sending to review (default behavior). Write specific, actionable steps: what to test in the UI, what edge cases to check, what areas might break. Not a restatement of the summary. PUBLICLY VISIBLE while the item is in review — write for an external reader and keep credentials, internal paths, and private URLs out of it.
touchedPathEvidenceNoProvenance for touchedPaths. Agent-supplied evidence is accepted but labeled lower confidence.
evidenceNotApplicableNoWhy review evidence the project expects for the change scope does not apply (e.g. "internal endpoint, no public contract change"). Recorded on the completion receipt and timeline.

Output Schema

NameRequiredDescriptionDefault
idYes
statusYes
messageNo
dashboardUrlNoFull dashboard URL of the affected resource
documentationNo
evidenceWarningsNo
completionReceiptNo
contextMaintenanceNo

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?

Annotations already declare idempotentHint=true and destructiveHint=false, and the description goes well past them: it discloses state-machine behavior, the `review_evidence_missing` blocking error, `evidenceWarnings`, that only artifacts since the reviewer's decision count, the public visibility of reviewInstructions, and wait exit codes (10/0/2/1) with a CLI-version caveat. This is unusually rich behavioral context.

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?

Long, but front-loaded with the core action and variant first, then organized under bold headers (Self-assessment, Before calling, Completion checklist, Pull request, etc.) so a reader can scan. A few sections restate schema descriptions subtly, costing it a perfect score, but nearly every sentence carries actionable instruction.

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 21-parameter, nested-object mutation tool with an output schema present, the description supplies the workflow sequencing, error conditions, and receipt semantics an agent needs to call it correctly. Return values are intentionally left to the output schema, and nothing critical for a correct invocation appears missing.

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 95%, so the baseline is 3, but the description adds genuine meaning beyond the schema: defaults for `outcome` and `deliveredScope`, that top-level `model`/`reasoningEffort` override nested selfAssessment values, when `checklistScope` must be supplied, and the bias toward broader scope. It doesn't explain every one of the 21 params, but it covers the semantically tricky ones.

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?

States a specific verb and resource ("Mark task as ready for review (in_review)") plus the immediate-done variant via `skipReview: true`, and explicitly distinguishes sibling paths: `request_review` tasks must wait for the reviewer, and `review_task` is the separate alternative. An agent can tell this apart from request_review/review_task/update_task without opening any schema.

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?

Names explicit when-to-use conditions ("use when the human explicitly asks" for skipReview; re-calling on an already in_review task moves to done) and the exclusions (tasks put in review with `request_review` are the exception). It also enumerates prerequisites in an ordered "Before calling" list, leaving little to inference.

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