Skip to main content
Glama

run_subagent

Delegate a scoped task to an AI sub-agent on Fluxion Bus and get a run ID to poll status or fetch results.

Instructions

Submit a local Fluxion executor as a sub-agent task.

By default (wait_for_result=false) this returns as soon as the task is queued: you get a run_id — poll get_task_status and read get_task_result once terminal. Set wait_for_result=true for small smoke checks that should block until done; if the wait elapses first the task continues in the background (queued or running, bounded by task_timeout_sec) and is collected later via get_task_result with the run_id (the run is not canceled). For long or open-ended work prefer the default. timeout_sec only limits this blocking wait; it is not the executor runtime limit. The actual task execution cap is settings.task_timeout_sec.

agent: "auto" (default; uses the configured default) or one of "claude", "codex", "antigravity".

workspace: directory the agent runs in. With a configured project, "." is the project root. WITHOUT a project (the default), pass an ABSOLUTE path to the target repo — "." resolves against the server's workspace_root, not the caller's cwd, so it is rarely what you want. Use list_projects to see configured projects.

profile/mode: for edit/fix/implement tasks set profile=implement and mode=workspace-write; the defaults profile=inspect / mode=read-only are intentionally read-only.

task_name: optional free-form label for the run. It is shown as-is in the UI and also slugified into the agent-path segment (lowercased, non [a-z0-9] runs collapsed to _), so spaces, uppercase, and hyphens are all accepted — no need to pre-format it.

model: optional per-run model override for executors that support model selection. Leave empty to use the executor's configured/default model. To choose explicitly, call list_agent_models first and pass one of the returned models[].id values. Do not pass price_references[].id; those entries are pricing context only and may not be accepted by the executor. model is not a provider selector: provider, base URL, and auth remain settings-level configuration. Ping tasks keep their cheapest-model default unless model is explicitly set.

thread / session_policy scope which executor session is reused. Default (empty thread) = a FRESH isolated session per call: independent tasks don't resume, so they can't inherit stale context or have their workspace edits reconciled away by a resumed agent. To CONTINUE a prior run (resume — reuses the agent's context, saving tokens), pass the SAME stable thread string on each call. session_policy is "auto" (default), "continue", or "new" (force a brand-new session even for a reused thread). Note: a resumed Antigravity run may reconcile the workspace to its remembered state, so avoid editing the workspace out-of-band between two same-thread runs.

Results: both are finalized only at terminal status (changed_files_available stays false until then). changed_files is the authoritative, run-scoped list of what THIS run touched — act on it. diff_summary.files mirrors that count, but its additions/deletions are NOT measured per run and are always 0, flagged by lines_counted=false — a whole-tree git diff --stat would fold in pre-existing edits and earlier runs, so no line total is reported rather than a misleading one. For exact line counts, run git diff over the changed_files yourself.

artifacts is not an inventory of files the run produced: it lists only files the agent explicitly declared for delivery via ACTIONS_JSON.upload_files, which it is prompted to do only when asked to send files. Screenshots and other by-products of the work appear in changed_files, not here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoread-only
agentNoauto
modelNo
promptYes
threadNo
profileNoinspect
projectNo
task_nameNo
workspaceNo.
parent_pathNo/root
timeout_secNo
include_stdoutNo
session_policyNoauto
wait_for_resultNo
include_subagent_preambleNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description carries full disclosure burden and does so extensively: asynchronous queuing, background continuation after timeout, freshness of sessions, resumed-run reconciliation risk, changed_files semantics, and artifacts only containing explicitly uploaded files. It also clarifies timeout_sec is only a blocking-wait limit, not a runtime cap.

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 organized into focused paragraphs with topic labels. It is front-loaded with the core behavior and every paragraph addresses a distinct concern; no filler or tautology.

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 15 parameters, zero annotations, and sparse schema descriptions, the description covers lifecycle, return semantics, timeout behavior, workspace resolution, session reuse, and result accuracy caveats. It even warns about Antigravity workspace reconciliation and artifacts semantics, making it more than sufficient for correct tool selection and invocation.

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 0%, but the description adds deep semantics for most parameters: wait_for_result, timeout_sec, agent, workspace, profile/mode, task_name slugification, model selection via list_agent_models, thread/session_policy, and settings.task_timeout_sec as the true executor cap. A few params (parent_path, include_stdout, include_subagent_preamble) are left unexplained, preventing a 5.

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 'Submit a local Fluxion executor as a sub-agent task,' using a specific verb and resource. It clearly distinguishes submission from sibling polling/result/cancellation tools and immediately orients the agent to its role.

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?

Provides explicit when-to-use guidance: default async vs wait_for_result=true for smoke checks, 'For long or open-ended work prefer the default,' and profile/mode selection for edit/fix tasks. Names sibling tools (get_task_status, get_task_result, list_projects, list_agent_models) as alternatives or prerequisites.

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/superposed-labs/fluxion-bus'

If you have feedback or need assistance with the MCP directory API, please join our Discord server