Skip to main content
Glama

start_task

Start a detached BoteX task and return its task_id immediately.

Instructions

Start a detached BoteX task and return its task_id immediately.

Runs the same engine as `run_subagent`, but returns instantly with a
`task_id` for polling via `get_task_status`. Concurrency is bounded by
engine.max_concurrent_tasks and the queue by engine.max_queued_tasks —
a full queue returns status TOO_MANY_QUEUED.

The capability/limits arguments are identical to `run_subagent` —
same contracts, same pre-authorization semantics:

- mode: capability preset — 'readonly' (read tools only; the contract
  is an analysis report), 'edit' (read + write; default), 'destructive'
  (+ delete/move), 'full' (+ run_command). Empty = engine.default_mode.
- allow_destructive / allow_exec / allow_net only ever WIDEN the
  preset, never narrow it — a readonly task cannot gain file writes.
  allow_exec additionally requires exec.enabled=true in the config.
  None of these is a sandbox: grant them only with the user's consent.
- output_path makes the contract file_output: DONE requires the file
  to exist, be non-empty, and pass the syntax gate (mutating mode).
- verify_command is an allowlisted command that must pass before DONE
  is accepted — it runs even when the task made no writes. Requires
  exec authorization.
- recipe: Optional operational persona / workflow prompt (e.g. 'planner',
  'code-explorer', 'reviewer', 'security-reviewer', 'build-resolver', 'tdd').
- max_turns / max_tokens / max_duration_s / budget_limit_usd:
  0 (negative for budget) = config value; a non-positive max_turns is
  clamped to 1.
- net_allowed_hosts / net_allowed_urls narrow or replace the net
  scope per run according to net.policy (see run_subagent).
- allow_non_zdr: per-run consent to relax Zero Data Retention — needed
  for free (:free) models whose endpoints may log or train on prompts.
  Same semantics as in run_subagent.

Returns:
    {"task_id": str, "status": "QUEUED"} — poll with get_task_status.
    The finished task's `result_data` carries the full engine result
    (status, failure_kind, ok, files_touched, exec_ran,
    rollback_verified, attempts[], cost_usd, ...).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo
taskYes
filesNo
modelNo
recipeNo
api_keyNo
profileNo
providerNo
allow_netNo
max_turnsNo
allow_execNo
max_tokensNo
output_pathNo
allow_non_zdrNo
workspace_dirNo
max_duration_sNo
verify_commandNo
budget_limit_usdNo
net_allowed_urlsNo
allow_destructiveNo
net_allowed_hostsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.1
    • changedInput schema / properties / workspace_dir / default
      Previous value: -"."New value: +""
  2. Changed1 schema field changedv1.0.1
    • addedInput schema / properties / allow_non_zdr
      Added value: +{
      +  "default": false,
      +  "title": "Allow Non Zdr",
      +  "type": "boolean"
      +}
  3. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: concurrency bounds (engine.max_concurrent_tasks), queue bound with the TOO_MANY_QUEUED failure status, the widening-only authorization semantics of allow_destructive/allow_exec/allow_net, the exec.enabled prerequisite, the DONE contract for output_path, and ZDR implications of allow_non_zdr. This is unusually rich disclosure of side effects and constraints.

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?

Front-loads the one-line summary and the async/poll relationship, then groups the capability arguments. Given 21 parameters, the length is largely earned, though a few bullets defer to 'see run_subagent' and the return-value section is somewhat redundant with the existing output schema.

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 complex 21-parameter mutation-capable tool with no annotations, the description covers startup behavior, queue semantics, authorization model, contract enforcement, and polling handoff. An agent has everything needed to invoke it correctly, and the output schema carries the detailed return shape.

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 description coverage is 0% across 21 parameters, so the description must compensate, and it explains the semantically tricky ones in depth (mode presets, widening-only flags, output_path contract, verify_command, recipe personas, budget/turn defaults, net scope narrowing). It leaves several parameters unexplained (files, model, api_key, profile, provider, workspace_dir), so coverage is strong but not complete.

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?

States a specific verb and resource ('Start a detached BoteX task') plus the immediately observable outcome ('return its task_id immediately'). It explicitly contrasts itself with the sibling run_subagent by being the fire-and-poll variant, so an agent can distinguish them without opening schemas.

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?

Names the alternative (run_subagent), explains the defining difference (returns instantly vs. blocking), and points to the follow-up tool (get_task_status) for polling. It stops short of stating explicit selection conditions such as 'use this when the task is long-running or may exceed a request timeout,' so it is clear but not fully prescriptive.

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