Skip to main content
Glama

build_async

Destructive

Start a long-running autonomous build in the background, returning immediately with a run_id. Poll job_status to watch progress or stop_job to cancel.

Instructions

Start an autonomous build in the BACKGROUND and return immediately.

Use when: the build may run for minutes and you want to keep working — this
returns a ``run_id`` right away instead of blocking (as the synchronous
``build`` does) until the run finishes. Poll ``job_status`` with the
``run_id`` to watch progress, ``stop_job`` to cancel, ``list_jobs`` to see
everything running. Do NOT use for a quick preview — use ``build`` with
``dry_run=True``. Related: ``build`` (synchronous), ``report`` (final outcome).

DESTRUCTIVE side effects (once running): edits files, makes git commits, and
calls an external LLM provider. Refuses to start a second job for a project
that already has one running (one writer per project).

Returns ``{run_id, status}`` on success, or ``{error}`` when a job is already
running for this project.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYesWhat to build, or a mode word ('debug', 'complete', 'review'). Example: 'add rate limiting to the public API'.
pathYesAbsolute path to the project directory to build. Its git working tree must be clean. Example: '/Users/me/code/my-api'.
budgetNoMaximum US dollars to spend; must be > 0.
parallelNoRun independent tasks concurrently in worktrees.
max_tasksNoCap how many tasks are planned/executed; >= 1.
reference_dirNoOptional reference implementation to port from (analyzed read-only). See the synchronous ``build`` tool.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Beyond destructiveHint=true, it details specific side effects (file edits, git commits, LLM calls) and the one-writer-per-project constraint, providing actionable knowledge for the agent.

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?

Concise ~100-word paragraph front-loaded with main action, followed by usage guidance, behavioral warnings, and return value. Every sentence is necessary.

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 complexity (6 params, output schema), the description covers async behavior, destructive effects, concurrency limits, and return format. It also references sibling tools for post-invocation actions.

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 coverage is 100%, so baseline is 3. The description adds little beyond cross-referencing 'reference_dir' to the synchronous build; no extra semantic enrichment.

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 clearly states the tool starts a build in the background and returns immediately. It distinguishes from the synchronous 'build' sibling by highlighting the non-blocking behavior.

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?

Explicitly tells when to use (long builds), when not to use (quick preview, use dry_run), and directs to related tools for monitoring and control (job_status, stop_job, list_jobs).

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/dcondrey/misterdev'

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