Skip to main content
Glama

complete_intent

Mark an active intent as completed after a git commit, updating its status and clearing it for new work. Handles failure stages and conflict detection.

Instructions

Mark the active intent as completed and clear it.

Call this after a successful git commit to:

  1. Update the intent status (committed/pushed/done/abandoned)

  2. Store the commit SHA for tracking

  3. Clear the active intent so a new one can be started

Status values:

  • "committed": Code is committed locally (default)

  • "pushed": Code has been pushed to remote

  • "done": Work is fully complete

  • "abandoned": Work was discarded without committing

REQUIRED: Inspect the response after calling this tool. Three outcomes:

  1. response.success === true: The task is complete. Briefly acknowledge the commit and — if response.committedDecisionCount > 0 — mention that N distilled architectural decisions were recorded for the intent. Do NOT enumerate the decisions inline; they're visible via the orchestration panel and via get_intent_decisions / get_relevant_context if the user wants details. If response.apiSyncDeferred === true, also mention that the API sync was deferred; the queued writes will replay on the next sync tick. If response.collisions is non-empty, a live collaborator's (HAI's) in-progress edits overlap the work you just completed — surface it as a coordination heads-up (who, and which files), naming response.collisions[].label and the files. It's advisory, not a failure; the completion still succeeded. If response.deferredConflicts is non-empty, the distillation produced N decisions that conflict with existing standards — the completion STILL SUCCEEDED (the commit landed: status flipped, code blocks captured). Those decisions are deferred: parked for a disposition in the Orchestration panel, where the user picks per decision: supersede the standard, keep both (records a "contradicts" edge for a deliberate divergence / false positive), or reject the distilled decision. Tell the user "N decision(s) need a disposition in the panel." There is NOTHING to retry — do NOT re-run complete_intent.

  2. response.success === false AND response.reason === "transient-failure": The distiller LLM call or the conflict-check API call errored. The ephemerals are preserved (the bucket is intact), and the intent stays "active". Tell the user the failure stage (response.failedStage) and the underlying error, then suggest retrying once the issue clears, or abandoning if the failure persists.

  3. In a non-interactive (autonomous) session: if response.deferredConflicts is non-empty, log it at INFO and continue — the commit already landed and the decisions await disposition in the panel. There is no blocking state.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoThe new status for the intent. Use "committed" after git commit, "done" when work is complete, "abandoned" to discard, "superseded" when another intent replaces this one.
intentIdNoTarget intent to complete/abandon. When omitted, completes THIS session's current intent. When provided, targets that specific intent directly — this is how you force-close an intent that is not your current one (e.g. another session's). Completing an intent created by ANOTHER team member additionally requires humanApproved=true (see below).
repoPathYesLocal path to the repository root
commitShaNoThe git commit SHA to associate with this intent (if already committed)
forkAuthorNoFork attribution; usually resolved by Muninn automatically — pass only for override / testing.
repoOriginNoGit remote origin URL. Auto-detected from repoPath via git if not provided.
workspaceIdNoWorkspace identifier; usually resolved by Muninn automatically — pass only for override / testing.
supersededByNoIntent ID that supersedes this one. Required when status is "superseded".
humanApprovedNoSet to true ONLY when the human has explicitly confirmed closing an intent created by ANOTHER team member. Required for that cross-author case; ignored for your own intents. NEVER set this on your own initiative — always ask the user first and only set it after they approve.
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the tool's actions: updating status, storing commit SHA, clearing the active intent. It details three possible response outcomes (success, transient failure, deferred conflicts) and instructs the agent on how to respond to each. This is exemplary transparency.

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 lengthy but well-structured with clear sections, bullet points for outcomes, and front-loaded purpose. While it could be more concise, every sentence adds necessary detail for correct tool invocation. The organization aids readability despite the length.

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?

Given the complexity (9 parameters, nested objects, no output schema), the description is remarkably complete. It covers all aspects: tool action, parameter usage, response handling, edge cases (transient failures, deferred conflicts), and even provides scripts for the agent to follow. This fully compensates for the lack of output schema and ensures the agent can use the tool correctly.

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?

All parameters are described in the schema (100% coverage), so the description's added value is in explaining parameter interactions and conditional usage (e.g., 'supersededBy' required when status is 'superseded', 'humanApproved' only for cross-author intents). This enhances understanding beyond schema definitions, justifying a score above baseline 3.

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 clearly states the tool's purpose: 'Mark the active intent as completed and clear it.' It specifies the verb ('complete') and resource ('active intent'), and distinguishes from sibling tools like 'update_intent' by focusing on completion and clearing. The description also provides concrete use cases (after git commit) and lists status values, making it highly specific.

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?

The description provides extensive usage context, including when to call (after successful git commit) and detailed response handling for different outcomes. It also explains status values and when to use parameters like 'humanApproved'. However, it does not explicitly state when NOT to use this tool or name direct alternatives, which is a minor gap. Still, the guidance is thorough and actionable.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kawacode-ai/kawa.mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server