Skip to main content
Glama

ouroboros_start_evaluate

Start a background evaluation of an execution artifact, returning a job ID immediately to prevent client timeouts. Later, poll job status and receive the verdict.

Instructions

Start an evaluation in the background and return a job ID immediately. Use this instead of ouroboros_evaluate when the three-stage pipeline (mechanical + semantic + optional consensus) is expected to exceed the MCP client tool-call timeout. Poll with ouroboros_job_status / ouroboros_job_wait and read the verdict via ouroboros_job_result. In plugin mode with auto_evolve disabled, evaluation is delegated to an OpenCode Task pane and job_id is None. With auto_evolve enabled, the parent keeps evaluation pollable so a rejection can start Ralph.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
artifactYesThe execution output/artifact to evaluate
session_idYesThe execution session ID to evaluate
auto_evolveNoOverride execution.auto_evolve for this background call. When true, an explicitly rejected formal evaluation starts a bounded Ralph continuation loop.
working_dirNoProject root used to resolve Stage 1 mechanical verification commands and Stage 2 source-file visibility. Commands are read from .ouroboros/mechanical.toml; when the file is missing, the evaluator makes one AI detect call that inspects manifests (package.json, pyproject.toml, Cargo.toml, Makefile, ...) and authors the toml. Stage 1 skips every check when no toml is produced — it never guesses.
seed_contentNoOriginal seed YAML for goal/constraints extraction
artifact_typeNoType of artifact: code, docs, config. Default: codecode
seed_handoff_idNoOpaque parent-owned Seed handle for plugin evaluation
trigger_consensusNoForce Stage 3 consensus evaluation. Default: False
acceptance_criteriaNoMultiple acceptance criteria for checklist evaluation. When two or more items are provided, each AC is evaluated independently and the results are aggregated into a pass/fail checklist (#366). Overrides acceptance_criterion.
acceptance_criterionNoSpecific acceptance criterion to evaluate against
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses the async job behavior, the None job_id delegation to an OpenCode Task pane in plugin mode without auto_evolve, and how auto_evolve keeps evaluation pollable for Ralph rejection. This goes well beyond the schema's basic parameter 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 four sentences of dense, useful content with no filler. It front-loads the core action, then provides alternative selection, polling workflow, and edge-case behavior, earning every sentence.

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?

There is no output schema and no annotations, so the description must explain the return contract, which it does: immediate job ID, None in certain plugin mode, and verdict via ouroboros_job_result. It also covers the key behavioral branches (plugin mode, auto_evolve), making it complete for a 10-parameter tool.

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 description coverage is 100% with each parameter already having a rich description. The top-level description does not add parameter-specific meaning; it focuses on workflow and alternatives, so the baseline score of 3 is appropriate.

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 a specific verb+resource: 'Start an evaluation in the background and return a job ID immediately.' It explicitly distinguishes from the sibling ouroboros_evaluate by positioning itself as the background variant for long-running pipelines, making its purpose unmistakable.

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?

It explicitly states when to prefer this over ouroboros_evaluate (when the three-stage pipeline is expected to exceed the MCP timeout) and names the exact sibling tools for polling and result retrieval (ouroboros_job_status, ouroboros_job_wait, ouroboros_job_result). It also covers plugin-mode and auto_evolve-specific usage.

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