Skip to main content
Glama

run_subagent

Delegate multi-step coding or refactoring tasks to an autonomous engine that edits local workspace files, validates patches, and returns verified structured results with rollback and cost tracking.

Instructions

Runs BoteX — an autonomous code execution engine (agent-agnostic harness).
BoteX performs multi-step tasks on local files inside workspace_dir.

TIP: If the user didn't specify a model, DO NOT guess. Use the `recommend_models` tool first to find the best model for this task!

Key engine features:
- Outline-First and Context Pruning: ~90% token savings.
- Pre-write Syntax Check: in-memory code validation before touching disk.
- Multi-tier Fuzzy Patching: tolerant of CRLF/LF and indentation drift.
- Hard Zero-Retention on OpenRouter (provider: data_collection=deny)
  and DLP secret censoring.
- Automatic Snapshot Rollback on loops or critical failures.

Args:
    task: Precise description of the coding or refactoring task.
    files: Optional list of primary files affected by the task.
    workspace_dir: Project directory path. Empty = engine.default_workspace
           from the config, else the server's current directory.
    model: Any model from the provider's catalog. Empty = model from config
           (see 'profile' and botex.config.json).
    profile: Model profile from botex.config.json (e.g. 'default', 'coding',
           'auto-beta', 'fast'). When both 'model' and 'profile' are empty,
           the capability mode picks the tier via engine.mode_profiles
           (readonly -> 'fast', destructive/full -> 'coding'). Ignored when
           'model' is given explicitly.
    provider: API provider from the 'providers' section of botex.config.json
           ('openrouter', 'nvidia', 'google', 'openrouter-free', 'ollama').
           Empty = provider marked 'default: true' in the configuration.
    mode: Capability preset: 'readonly' (read only — the contract is an
           analysis report, DONE requires non-empty findings), 'edit'
           (read + edit — default), 'destructive' (+delete/move),
           'full' (+run_command). Empty = engine.default_mode from
           config. Explicit allow_* flags may only WIDEN a preset —
           they never narrow it (readonly can never gain file writes).
           In headless mode this is pre-authorization — grant it
           consciously.
    max_turns: Maximum tool-loop steps (0 = config value).
    max_tokens: Per-turn completion cap (0 = config value; reasoning
           models need ~8000+ since thinking shares this budget).
    max_duration_s: Total wall-clock limit in seconds (0 = config value,
           0 disables only when config is also 0). Checked between turns.
    budget_limit_usd: Daily spend limit in USD (negative = config value,
           0 = no limit).
    allow_destructive: Authorize destructive operations (delete_file/
           move_file) for this task. Headless mode cannot confirm
           mid-run — grant ONLY with the user's consent.
    allow_exec: Authorize run_command for this task (also requires
           exec.enabled=true in config). WARNING: this is NOT a sandbox —
           commands run with operator privileges. Grant only for trusted
           workspaces with the user's consent.
    api_key: Optional provider API key passed per-request (highest
           priority — overrides env/.env/config). Empty = resolved
           internally by the harness.
    output_path: Optional required output file (workspace-relative).
           Sets the file_output contract: DONE is accepted only when
           the file exists on disk, is non-empty, and passes the
           syntax gate; a DONE response carrying the payload as text
           is salvaged to disk. Requires a mutating mode.
    allow_net: Explicitly authorizes the read-only public web tool for
           this run. It is never enabled by a capability mode.
    net_allowed_hosts: Optional per-run host authorization. In
           net.policy='caller' these replace config defaults; in 'public'
           they narrow public access; in 'allowlist' they must stay inside
           net.allowed_hosts.
    net_allowed_urls: Optional per-run URL authorization rules. A URL
           ending in '/' authorizes that subtree; otherwise it authorizes
           the exact URL including its query string.
    verify_command: Optional allowlisted command that must pass before
           DONE is accepted — it runs against the workspace as it
           stands, including when the task made no writes (a passing
           verifier validates a legitimate no-change result). Requires
           exec.enabled=true in config and exec authorization.
    recipe: Optional operational persona / workflow prompt (e.g. 'planner',
           'code-explorer', 'reviewer', 'security-reviewer', 'build-resolver', 'tdd').
    allow_non_zdr: Per-run consent to relax the Zero Data Retention
           gate. Required for free (:free) models whose endpoints may
           log or train on prompts — it also switches the wire
           provider.data_collection flag to 'allow'. Grant only with
           the operator's consent; the result carries
           zdr_enforced=false. The openrouter-free provider preset is
           the persistent config-level alternative.
    approval_policy: Operator approval policy for risky operations: 'none',
           'high_risk' (default), 'mutations', 'all_risky'.

Returns:
    A pretty-text report in the text content (unchanged format for legacy
    clients) plus the full engine result as structuredContent (status,
    failure_kind, ok, files_touched, exec_ran, rollback_verified,
    attempts[], cost_usd, ...). `ok` is true only when status == DONE —
    i.e. the task contract was verified, not merely claimed by the model.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task": "<task>"
    },
    "name": "run_subagent"
  }
}

Input 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
approval_policyNo
budget_limit_usdNo
net_allowed_urlsNo
allow_destructiveNo
net_allowed_hostsNo

Output Schema

NameRequiredDescriptionDefault
okNo
stepsNo
statusNo
messageNo
summaryNo
task_idNo
attemptsNo
cost_usdNo
exec_ranNo
duration_sNo
lines_addedNo
memory_keysNo
failure_kindNo
zdr_enforcedNo
artifact_refsNo
fallback_fromNo
files_touchedNo
lines_removedNo
applied_skillsNo
blocking_reasonNo
vault_memory_idNo
rollback_verifiedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.1.2
    • addedInput schema / properties / approval_policy
      Added value: +{
      +  "default": "",
      +  "title": "Approval Policy",
      +  "type": "string"
      +}
    • addedOutput schema / properties / applied_skills
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "title": "Applied Skills",
      +  "type": "array"
      +}
    • addedOutput schema / properties / artifact_refs
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "title": "Artifact Refs",
      +  "type": "array"
      +}
    • addedOutput schema / properties / blocking_reason
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "title": "Blocking Reason"
      +}
    • addedOutput schema / properties / memory_keys
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "title": "Memory Keys",
      +  "type": "array"
      +}
    • addedOutput schema / properties / vault_memory_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "title": "Vault Memory Id"
      +}
  2. Changed1 schema field changedv1.1.1
    • changedInput schema / properties / workspace_dir / default
      Previous value: -"."New value: +""
  3. Changed3 schema fields changedv1.0.1
    • addedInput schema / properties / allow_non_zdr
      Added value: +{
      +  "default": false,
      +  "title": "Allow Non Zdr",
      +  "type": "boolean"
      +}
    • addedOutput schema / $defs / SubagentAttemptResult / properties / zdr_enforced
      Added value: +{
      +  "title": "Zdr Enforced",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / zdr_enforced
      Added value: +{
      +  "title": "Zdr Enforced",
      +  "type": "boolean"
      +}
  4. First observedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so richly: it discloses zero-retention/DLP behavior, snapshot rollback, syntax checking, fuzzy patching, capability modes, headless pre-authorization semantics, command execution risk, and how DONE/ok is verified. This is unusually complete disclosure for a complex execution tool.

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 the length is justified by 22 parameters, no annotation coverage, and a complex execution harness. It is front-loaded with purpose and structured into feature, argument, and return sections, though some marketing-style feature bullets are denser than strictly necessary for invocation.

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 the tool's complexity, 22 parameters, absence of annotations, and presence of an output schema, the description is complete enough for an agent to invoke it correctly. It covers defaults, safety constraints, mode interactions, return semantics, and failure/verification behavior.

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?

Although schema description coverage is 0% and there are 22 parameters, the description documents every parameter with meaning, defaults, interactions, and warnings. Examples include mode presets, model/profile/provider resolution order, output_path contract behavior, network authorization rules, and approval_policy values, so it fully compensates for the empty schema descriptions.

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 states a specific action and resource: it runs BoteX, an autonomous code execution engine, to perform multi-step tasks on local files inside workspace_dir. That is far more specific than a tautology and gives the agent a concrete mental model of the tool's role.

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?

It gives explicit guidance for model selection ('DO NOT guess... use recommend_models first') and extensive warnings about when to grant permissions such as allow_exec, allow_destructive, and allow_non_zdr. However, it does not explicitly contrast this tool with the sibling start_task, so selection between those alternatives is still partly left to inference.

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