Skip to main content
Glama

Start Async Pipeline (DAG of predictions)

replicate_pipeline_start

Run a directed acyclic graph of Replicate predictions as a background job; independent steps run concurrently and downstream steps auto-start. Returns a pipeline_id for polling status.

Instructions

Run a directed acyclic graph (DAG) of Replicate predictions as a background job. Returns a pipeline_id immediately. Poll replicate_pipeline_status for per-step progress and results.

Independent steps run concurrently. Downstream steps auto-start when their dependencies complete. Use "$stepId.field[n]" template strings to pass one step's output as another step's input.

IMPORTANT: model must be a full Replicate identifier ("owner/name" or "owner/name:version"). Curated shortcuts (e.g. "flux-schnell") are not supported — look up the full id via replicate_get_model_schema.

Template reference syntax: "$gen.urls[0]" → first URL output of step "gen" "$gen.urls" → full URLs array "$gen.local_paths[0]" → first downloaded local path "$gen.text_output[0]" → first text output (for LLMs)

Args:

  • steps (array, 1–20): Pipeline steps. Each: { id, model, input, depends_on? }. depends_on is inferred from $ref patterns in input when omitted.

  • concurrency (1–5, default 3): Max simultaneous steps.

  • download (boolean, default true): Download step outputs locally.

  • timeout_ms_per_step (default 300000): Per-step timeout.

  • ttl_hours (1–72, default 1): How long to keep results in memory. Lost on server restart.

Returns: { pipeline_id, total, message }

Example — generate + upscale + remove background in parallel: steps=[ { "id": "gen", "model": "black-forest-labs/flux-schnell", "input": { "prompt": "a fox" } }, { "id": "upscale", "model": "nightmareai/real-esrgan", "input": { "image": "$gen.urls[0]", "scale": 4 } }, { "id": "no_bg", "model": "lucataco/remove-bg", "input": { "image": "$gen.urls[0]" } } ] upscale and no_bg both depend on gen, run in parallel after gen completes.

Input Schema

NameRequiredDescriptionDefault
stepsYesPipeline steps. 1–20 steps.
downloadNoDownload step outputs locally. Default: true.
ttl_hoursNoHow long to keep pipeline results in memory (1–72h). Default: 1h. State is lost if the server restarts.
concurrencyNoMax simultaneous steps (1–5). Default: 3.
timeout_ms_per_stepNoPer-step prediction timeout ms (5000–1800000). Default: 300000 (5min).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.3.1
    • addedInput schema / properties / steps / items / properties / input / propertyNames
      Added value: +{
      +  "type": "string"
      +}
  2. First observedv3.2.3

TDQS

A4.4/5.0
Behavior4/5

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

Adds real behavioral context beyond the annotations: async fire-and-return, concurrent independent steps, automatic downstream start, inferred dependencies, and per-step timeouts. Some of this (TTL expiry on server restart) merely restates the schema's ttl_hours description, so it is not purely additive, but the execution model disclosure is valuable.

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?

Front-loaded with purpose, then mechanism, then constraints, then args, then example — good ordering. The Args block re-lists defaults and ranges already in the schema, which is the one place text fails to earn its space.

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 the description compensates by declaring the return shape ({ pipeline_id, total, message }) plus where the actual results live (poll the status tool). Given a 5-parameter, 20-item nested array tool with async semantics, an agent has everything needed to call it correctly.

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 100%, so the Args section is largely redundant, but the description earns credit for the template reference syntax ($gen.urls[0], $gen.local_paths[0], $gen.text_output[0]) and the rule that depends_on is inferred from $ref patterns — semantics an agent cannot confidently derive from the schema alone. The worked three-step example seals it.

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?

States a specific verb and resource — run a DAG of Replicate predictions as a background job — plus the immediate return value (pipeline_id). It also distinguishes itself from the other ~20 single-call generation siblings by scoping to multi-step async pipelines, and names replicate_pipeline_status as the follow-up.

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?

Clearly tells the agent to poll replicate_pipeline_status and to look up full model ids via replicate_get_model_schema before calling. What's missing is an explicit contrast with replicate_batch_start, the closest sibling for running many predictions, which an agent would have to disambiguate on its own.

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