Skip to main content
Glama

Delimit Agent Complete

delimit_agent_complete

Close a dispatched engineering task by recording its result and changed files, marking it completed so dashboards stop counting it as in-flight.

Instructions

Close a dispatched agent task by recording the outcome.

When to use: at the end of an engineering subagent's work, to record the result summary and the files touched on the dispatch record. This is the closing step of the dispatch lifecycle (delimit_agent_dispatch -> [subagent runs] -> this). Without calling this, the task remains "dispatched" in the ledger and dashboards will count it as in-flight. When NOT to use: to hand off ownership to a different model (use delimit_agent_handoff), to dispatch a fresh task (delimit_agent_dispatch), or to read task status without closing (delimit_agent_status). Also: do not call repeatedly on the same task_id — the backend treats a second complete as an error.

Sibling contrast: delimit_agent_handoff transfers active ownership to another model (task stays open); this closes ownership entirely. delimit_agent_status is the read-only sibling.

Side effects: writes a completion record via ai.agent_dispatch.complete_task — the task's status flips from "dispatched" to "completed", result and files_changed are persisted, and an audit log entry is appended. files_changed is coerced from a comma string to a list. No license gate on this lifecycle surface. No notification — pair with delimit_notify if the operator needs to be told.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultNoSummary of what was done.
task_idYesTask id from delimit_agent_dispatch. Required.
files_changedNoComma-separated paths of modified files.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changedv4.7.9
    • addedInput schema / properties / files_changed / description
      Added value: +"Comma-separated paths of modified files."
    • addedInput schema / properties / result / description
      Added value: +"Summary of what was done."
    • addedInput schema / properties / task_id / description
      Added value: +"Task id from delimit_agent_dispatch. Required."
  2. Addedv4.5.5

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the full side-effect profile: writes a completion record, flips task status from 'dispatched' to 'completed', persists result and files_changed, appends an audit log entry, coerces files_changed from a comma string to a list, and confirms no license gate or notification. This level of behavioral disclosure is exemplary.

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

Conciseness5/5

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

The description is structured into clear labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence carries actionable information with no filler, and the core purpose is front-loaded before the details.

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?

The description fully covers the tool's place in the dispatch lifecycle, its mutation semantics, its exclusions, and its behavioral caveats. Even with an output schema present, nothing needed for correct invocation is 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?

The schema already covers all three parameters (100% coverage), so the baseline is 3. The description adds useful extra semantics by explaining that task_id originates from delimit_agent_dispatch and that files_changed is coerced from a comma string to a list, which the schema does not state.

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 opens with a specific verb and resource: 'Close a dispatched agent task by recording the outcome.' It clearly distinguishes itself from the sibling tools by explicitly contrasting with delimit_agent_dispatch, delimit_agent_handoff, and delimit_agent_status.

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?

Provides an explicit 'When to use' section with a concrete lifecycle position, and a 'When NOT to use' section naming the exact alternative tools. It also warns against repeated calls on the same task_id, which is exactly the kind of disambiguation an agent needs.

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/delimit-ai/delimit-mcp-server'

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