Skip to main content
Glama

ouroboros_start_auto

Start or resume an Ouroboros automation in the background, obtaining session and job IDs to monitor progress and retrieve final results.

Instructions

Start ooo auto in the background and return auto_session_id + job_id immediately. Resume with the returned auto_session_id; poll with ouroboros_job_status / ouroboros_job_wait and read final state via ouroboros_job_result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory
goalNoGoal/task for ooo auto
domainNoOptional domain profile name (for example, coding)
resumeNoAuto session id to resume
skip_runNoStop after A-grade Seed
attach_jobNoAttach an externally verified job id to an unknown run handoff
attach_sourceNoSource label for an attached run handle
commit_policyNoCheckpoint commit policy: ac_checkpoint, final_only, or none
reconcile_runNoTry to reconcile an unknown run handoff without starting a duplicate run
attach_sessionNoAttach an externally verified run session id to an unknown run handoff
efficiency_modeNoExecution efficiency policy: adaptive may use lower-cost child tiers with recovery escalation; quality_first keeps child ACs at the parent starting tier. Default: adaptive.
worktree_policyNoWorktree isolation policy: auto, always, current, or none
attach_executionNoAttach an externally verified execution id to an unknown run handoff
complete_productNoWhen true, chain RUN → RALPH_HANDOFF after a successful run handoff so a single ouroboros_auto invocation iterates Ralph until QA passes, convergence, or a budget bound trips. Defaults to false (opt-in).
reconcile_sourceNoSource label for run handoff reconciliation
user_preferencesNoCaller-supplied user preferences keyed by ledger section name (e.g. runtime_context, constraints, non_goals). The Driver tags matching answers with [from-auto][user_preference] in the ledger. Keys must be valid ledger section names; values must be non-empty strings or non-empty lists of strings/numbers. On resume, null/empty values clear the persisted preference for that section.
max_repair_roundsNoMax repair rounds
frugality_assuranceNoFrugality assurance: off, observe, or explicitly authorized strict. Defaults from efficiency_mode and is immutable on resume.
max_interview_roundsNoMax interview rounds
pipeline_timeout_secondsNoTop-level pipeline deadline in seconds. Defaults to 7200s for new sessions. Range: 60-86400. Cannot be changed on resume; the deadline is preserved across process restarts.
Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden. It reveals that execution is asynchronous ('in the background'), non-blocking ('return ... immediately'), resumable, and that the final state must be read via other tools. It does not cover failure modes, cancellation, or resource implications, but the key behavioral traits are communicated.

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?

Two sentences, front-loaded with the core action and return values, and every clause provides essential workflow information. No filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the complete high-level flow: start, resume, poll, and read result, which is sufficient for a 20-parameter tool with 0 required params and comprehensive schema descriptions. It does not describe all possible parameter interactions, but the schema already provides field-level detail.

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 every parameter already has a description. The tool description adds no parameter-level semantics beyond noting that a returned auto_session_id can be used for resume, which indirectly supports the resume parameter. Baseline 3 is appropriate since schema does the heavy lifting.

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 a specific action: 'Start ooo auto in the background' and specifies the immediate return values ('auto_session_id + job_id'). This distinguishes it from siblings like ouroboros_auto by emphasizing the background/asynchronous nature.

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 gives clear context for use: launch in the background and get immediate IDs. It also provides a follow-up workflow ('Resume with the returned auto_session_id; poll with ouroboros_job_status / ouroboros_job_wait and read final state via ouroboros_job_result'), though it does not explicitly contrast this tool with ouroboros_auto or list exclusion scenarios.

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/Q00/ouroboros'

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