Skip to main content
Glama

start_task

Launch a background coding task and get a task ID for immediate polling. Retrieve full engine results later, with queue limits and rollback tracking.

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).

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
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. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

There are no annotations, so the description carries the full behavioral burden. It discloses detached execution, queue-full behavior, capability preset semantics, widening-only allow flags, the non-sandbox warning, output_path file requirements, verify_command authorization, default/clamping behavior, and the return payload. This is far more transparent than typical tool descriptions.

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 long but every section earns its place: purpose, engine comparison, queue behavior, argument semantics, and return values. The bullet-list structure makes the dense parameter details scannable, and the most important decision-relevant information is front-loaded.

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 20 parameters, no schema-level descriptions, and no annotations, the description is remarkably complete. It covers invocation semantics, concurrency and queue limits, return shape, polling route, and safety caveats, while also pointing to run_subagent for shared contracts. An output schema exists, and the description still summarizes the returned task_id/status and result_data fields.

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

Parameters5/5

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

Schema description coverage is 0%, and the description compensates with detailed bullet semantics for mode, allow_destructive/allow_exec/allow_net, output_path, verify_command, recipe, limit parameters, and net_allowed_hosts/urls. It also routes shared contracts to run_subagent. The remaining parameters are self-explanatory from their names, types, and default values.

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 first sentence states a specific verb and resource: 'Start a detached BoteX task and return its task_id immediately.' It also contrasts with the sibling runner run_subagent ('returns instantly'), so an agent can immediately distinguish this asynchronous submission tool from the synchronous alternative.

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?

The description makes the usage context clear: use this tool when you want the same engine as run_subagent but need a task_id to poll via get_task_status. It also gives operational conditions such as bounded concurrency and TOO_MANY_QUEUED. It does not explicitly state a when-not-to-use rule, but the contrast with run_subagent and the polling pointer provide sufficient guidance.

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