Skip to main content
Glama

_delimit_agent_impl

Records and tracks agent task lifecycle actions: dispatch intent, check status, handoff to another model, or close tasks. Use for task planning and audit instead of direct execution.

Instructions

Manage the agent-task lifecycle — dispatches to one of four actions.

When to use: as the single MCP-registered agent surface (delimit_agent) when the caller wants to pick the lifecycle action by name in one call rather than choosing a specific delimit_agent_* alias. The lifecycle is dispatch (record intent) -> status (read) -> handoff (transfer to another model) -> complete (close). When NOT to use: from internal code paths — prefer the specific alias (delimit_agent_dispatch, delimit_agent_status, delimit_agent_complete, delimit_agent_handoff) so the action's docstring and arg schema show up at the right call site. Do NOT use action="dispatch" expecting a subagent to run — it RECORDS the dispatch, it does not execute it (see Side effects). The related delimit_agent_link / _policy / _check / _dashboard tools share the prefix but are SEPARATE tools, not actions here — passing their names as action= returns an "Unknown action" error.

Sibling contrast: delimit_agent_dispatch / _status / _complete / _handoff are thin aliases that call straight into this implementation with a fixed action; they exist so each action's docstring lives at the right name. This is the dispatch core for those four. Versus delimit_ledger_add: the ledger holds free-form work items; this surface carries engineering-dispatch schema (assignee, tools_needed, constraints) and a per-task audit trail.

Side effects: action="status" is READ-ONLY (loads the task store, no writes). action="dispatch" / "complete" / "handoff" WRITE to the agent task store and append to its audit log. CRITICAL: action="dispatch" records intent only — it persists a task plus a formatted agent_prompt and does NOT spawn or run a subagent. Per the operating model, actual execution is the caller's responsibility via the Agent tool (subagent_type=engineering); this is the planning + audit surface. Dispatch additionally enforces deterministic guards before writing: a kill switch (refuses if ~/.delimit/pause_dispatch exists), a dead- letter circuit breaker (auto-pauses once too many tasks remain un-acknowledged), a ghost-title reject, and a shipped-LED anti- duplicate gate (refuses + auto-closes a task whose LED is already merged to main). assignee="any" is resolved to a concrete model via the task-type router. Every return is wrapped via _with_next_steps. Errors are deterministic ({"error": ...}): an unknown action short- circuits before any backend call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoWhich lifecycle operation to perform. One of "dispatch", "status", "complete", "handoff". Default "status". Any other value returns a deterministic {"error": "Unknown action ..."}.status
titleNoTask title (action="dispatch" only). Required — the backend rejects empty titles.
descriptionNoLonger task description (action="dispatch" only).
assigneeNoTarget model "claude"/"codex"/"gemini"/"any" (action="dispatch" only). Default "any", resolved to a concrete model by the router. Invalid values are rejected.any
priorityNo"P0"/"P1"/"P2" (action="dispatch" only). Default "P1"; invalid values are rejected.P1
tools_neededNoComma-separated MCP tools the work will need (action="dispatch" only). Coerced to a list.
constraintsNoComma-separated constraints, e.g. "no force push" (action="dispatch" only). Coerced to a list.
contextNoBackground to seed the executor (action="dispatch") OR notes for the next model (action="handoff"). Unused by status/complete.
task_idNoTask id, e.g. "AGT-A1B2C3D4". Used by status, complete, handoff. Optional for status (empty lists all active tasks); required and validated for complete/handoff.
resultNoSummary of what was done (action="complete" only).
files_changedNoComma-separated modified file paths (action="complete" only). Coerced to a list.
to_modelNoTarget model for the transfer (action="handoff" only). Required; validated against the allowed models.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

No annotations provided, but the description fully discloses side effects: status is read-only, other actions write and audit, dispatch only records intent. It details deterministic guards (kill switch, circuit breaker, ghost-title reject) and error format. This exceeds the burden typically expected.

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 front-loaded with the core summary, then well-structured into usage guidelines and side effects. While verbose with guard details, every part earns its place given the tool's complexity. Slight verbosity keeps it from a 5.

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 12 parameters, 4 actions, multiple guards, and an output schema, the description covers the lifecycle, per-action parameter usage, side effects, error handling, and sibling relationships. No gaps remain.

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. The description adds contextual nuance: which parameters apply to which actions, how 'context' differs for dispatch vs handoff, 'task_id' optional for status but required for complete/handoff. This adds meaningful value beyond the schema.

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 it manages the agent-task lifecycle and dispatches to one of four actions. It distinguishes from siblings by naming thin aliases and contrasting with other delimit tools like delimit_ledger_add.

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?

Explicit when to use (single MCP surface for lifecycle actions) and when not to use (internal code paths preferring specific aliases). It warns about misconception that 'dispatch' executes, and clarifies separate tools that share the prefix.

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