Skip to main content
Glama

Delimit Agent Impl

_delimit_agent_impl

Manage the agent-task lifecycle through four actions: dispatch to record intent, status to read progress, handoff to transfer to another model, and complete to close tasks.

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
titleNoTask title (action="dispatch" only). Required — the backend rejects empty titles.
actionNoWhich lifecycle operation to perform. One of "dispatch", "status", "complete", "handoff". Default "status". Any other value returns a deterministic {"error": "Unknown action ..."}.status
resultNoSummary of what was done (action="complete" only).
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.
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
to_modelNoTarget model for the transfer (action="handoff" only). Required; validated against the allowed models.
constraintsNoComma-separated constraints, e.g. "no force push" (action="dispatch" only). Coerced to a list.
descriptionNoLonger task description (action="dispatch" only).
tools_neededNoComma-separated MCP tools the work will need (action="dispatch" only). Coerced to a list.
files_changedNoComma-separated modified file paths (action="complete" only). Coerced to a list.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. Changed12 schema fields changedv4.13.1
    • changedInput schema / properties / action / description
      Previous value: -"Which agent operation to perform."New value: +"Which lifecycle operation to perform. One of \"dispatch\",\n\"status\", \"complete\", \"handoff\". Default \"status\". Any other\nvalue returns a deterministic {\"error\": \"Unknown action ...\"}."
    • changedInput schema / properties / assignee / description
      Previous value: -"Target model claude/codex/gemini/any (for action='dispatch')."New value: +"Target model \"claude\"/\"codex\"/\"gemini\"/\"any\"\n(action=\"dispatch\" only). Default \"any\", resolved to a\nconcrete model by the router. Invalid values are rejected."
    • changedInput schema / properties / constraints / description
      Previous value: -"Comma-separated constraints (for action='dispatch')."New value: +"Comma-separated constraints, e.g. \"no force push\"\n(action=\"dispatch\" only). Coerced to a list."
    • changedInput schema / properties / context / description
      Previous value: -"Background info (for dispatch) or handoff context (for handoff)."New value: +"Background to seed the executor (action=\"dispatch\") OR\nnotes for the next model (action=\"handoff\"). Unused by\nstatus/complete."
    • changedInput schema / properties / description / description
      Previous value: -"Task description (for action='dispatch')."New value: +"Longer task description (action=\"dispatch\" only)."
    • changedInput schema / properties / files_changed / description
      Previous value: -"Comma-separated files modified (for action='complete')."New value: +"Comma-separated modified file paths\n(action=\"complete\" only). Coerced to a list."
    • changedInput schema / properties / priority / description
      Previous value: -"P0/P1/P2 (for action='dispatch')."New value: +"\"P0\"/\"P1\"/\"P2\" (action=\"dispatch\" only). Default \"P1\";\ninvalid values are rejected."
    • changedInput schema / properties / result / description
      Previous value: -"Summary of what was done (for action='complete')."New value: +"Summary of what was done (action=\"complete\" only)."
    • changedInput schema / properties / task_id / description
      Previous value: -"Task ID e.g. AGT-A1B2C3D4 (for status/complete/handoff)."New value: +"Task id, e.g. \"AGT-A1B2C3D4\". Used by status, complete,\nhandoff. Optional for status (empty lists all active tasks);\nrequired and validated for complete/handoff."
    • changedInput schema / properties / title / description
      Previous value: -"Task title (for action='dispatch')."New value: +"Task title (action=\"dispatch\" only). Required — the backend\nrejects empty titles."
    • changedInput schema / properties / to_model / description
      Previous value: -"Target model for handoff (for action='handoff')."New value: +"Target model for the transfer (action=\"handoff\" only).\nRequired; validated against the allowed models."
    • changedInput schema / properties / tools_needed / description
      Previous value: -"Comma-separated tools list (for action='dispatch')."New value: +"Comma-separated MCP tools the work will need\n(action=\"dispatch\" only). Coerced to a list."
  2. Addedv4.5.5

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the minimal readOnlyHint/destructiveHint annotations, the description discloses exactly which actions read vs write, that dispatch only records intent and never runs a subagent, the deterministic guards (kill switch, circuit breaker, ghost-title reject, anti-duplicate), and the consistent error shape. This fully covers the behavioral profile an agent needs.

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 long, but it is organized into clear sections and front-loaded with the most important usage facts. It loses a point for a couple of deliberate redundancies, such as the repeated warning that dispatch records rather than executes, but overall the density is justified by the tool's four-action complexity.

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 multi-action dispatcher with a large sibling family and 12 parameters, the description covers when to use it, what each action does, side effects, guards, errors, and relationship to aliases and adjacent tools. An output schema exists, so return-value detail is not the description's burden.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents each parameter's action-specific meaning and defaults. The description adds context around dispatch's effect (persisting agent_prompt) but does not materially add parameter-level detail beyond the schema, so the high-coverage baseline of 3 is appropriate.

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 ('Manage the agent-task lifecycle') and immediately names the four actions: dispatch, status, handoff, complete. It also distinguishes the tool from the delimit_agent_* aliases and from delimit_ledger_add, so an agent can tell exactly what this surface is for.

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' and 'When NOT to use' sections tell the agent to select this combined surface for name-based action selection and to prefer the specific delimit_agent_* aliases from internal code paths. It even warns against expecting dispatch to execute a subagent and names the separate prefix-sharing tools that are not actions.

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