Skip to main content
Glama

complete_intent

After a successful git commit, complete the active intent: update its status (committed/pushed/done/abandoned), store the commit SHA, and clear it to start a new intent.

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?

No annotations provided, so description carries full burden. It details outcomes (success, transient failure, deferred conflicts, collisions) and how to handle each. Highly transparent.

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 well-structured with numbered outcomes and status list. Front-loaded with core purpose. Could be slightly more concise but still effective.

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 9 parameters, no output schema, and complex error handling, the description covers all major behaviors, error states, and response processing. Describes response fields adequately.

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 baseline is 3. Description adds meaning by explaining status usage, intentId cross-author behavior, and humanApproved policy.

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 marks an intent as completed and clears it. It specifies the verb, resource, and context ('after successful git commit'), distinguishing it from siblings like update_intent or create_and_activate_intent.

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?

Explicitly states when to use (after git commit) and lists status values with meanings. Does not explicitly compare to alternatives but context is clear enough.

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/CodeAwareness/kawa.mcp'

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