Skip to main content
Glama

Run pipeline

run_pipeline
Destructive

Start a pipeline run in the background and return its runId immediately. Video pipelines take minutes; poll get_run for progress. Runs consume account credits. inputs is keyed by entry node id (get_pipeline lists them as entryNodes): a Text Input node takes text, an HTTP Payload node takes a JSON value, and a File node takes a URL that overrides the file placed on the canvas, so a clipping pipeline can be pointed at a new source video per run without editing the graph. An entry node left out runs with the value saved on the canvas; one with nothing saved is refused, so pass it (or "" to leave it blank on purpose), and ask the user what it should say when the request does not tell you. A key that names no entry node is refused before anything runs or is charged. Before running a pipeline you built or changed in this conversation, call estimate_run_cost, wait for the person to accept the price, and pass its quoteId here: the run starts only if the pipeline is still the one quoted, and only once, so calling again with the same quoteId (a retry, a second "yes") returns the run already started instead of charging for another. Without a quote, pass a requestId of your own for the same protection on a retry. Every run renders every node again, so to add music, narration or captions to a video an earlier run made, pass its url from get_run outputs to assemble_video (musicPrompt composes a bed) or edit_asset rather than editing the pipeline and running it again.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pipelineId": "<pipelineId>"
    },
    "name": "run_pipeline"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputsNo
previewNoRender a cheap first look instead of the whole run: the first video step and the steps that feed it, as one Veo 3.1 Lite clip of up to 8 seconds at 720p. estimate_run_cost and a refused run quote it as `preview` when the balance does not cover the run. Only on the person's yes. Returns the pipelineId get_run needs, which is not this pipeline's.
quoteIdNoThe quoteId estimate_run_cost (or make_video) returned for this pipeline, once the person accepted that price.
requestIdNoAny id you choose for this one request, e.g. a fresh UUID. Repeat it only when retrying this same request: a call with an id that already started a run returns that run instead of starting another. Not needed with quoteId.
pipelineIdYes
callbackUrlNoAn https URL Treza POSTs the finished run to, once, when it ends (success, partial, error or cancelled), so an automation can wait for the render instead of polling get_run. The body is the JSON get_run returns for the run, sent with the headers X-Treza-Event: run.finished and X-Treza-Delivery: <runId>. It must be https on the default port and reach a public address; a URL that does not is refused before anything runs or is charged. Each attempt waits 10 seconds for a 2xx, and a timeout, 408, 429 or 5xx is retried twice more.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / callbackUrl
      Added value: +{
      +  "description": "An https URL Treza POSTs the finished run to, once, when it ends (success, partial, error or cancelled), so an automation can wait for the render instead of polling get_run. The body is the JSON get_run returns for the run, sent with the headers X-Treza-Event: run.finished and X-Treza-Delivery: <runId>. It must be https on the default port and reach a public address; a URL that does not is refused before anything runs or is charged. Each attempt waits 10 seconds for a 2xx, and a timeout, 408, 429 or 5xx is retried twice more.",
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / quoteId
      Added value: +{
      +  "description": "The quoteId estimate_run_cost (or make_video) returned for this pipeline, once the person accepted that price.",
      +  "maxLength": 64,
      +  "type": "string"
      +}
    • addedInput schema / properties / requestId
      Added value: +{
      +  "description": "Any id you choose for this one request, e.g. a fresh UUID. Repeat it only when retrying this same request: a call with an id that already started a run returns that run instead of starting another. Not needed with quoteId.",
      +  "maxLength": 128,
      +  "minLength": 1,
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / preview
      Added value: +{
      +  "description": "Render a cheap first look instead of the whole run: the first video step and the steps that feed it, as one Veo 3.1 Lite clip of up to 8 seconds at 720p. estimate_run_cost and a refused run quote it as `preview` when the balance does not cover the run. Only on the person's yes. Returns the pipelineId get_run needs, which is not this pipeline's.",
      +  "type": "boolean"
      +}
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations (destructive/write/open-world) by disclosing credit consumption, quote-pinning semantics (same quoteId returns the already-started run, starts only if the pipeline matches the quote), requestId retry protection, the refusal-before-charge behavior for unknown keys and unset entry nodes, and the fact that every run re-renders every node. The conditional replay on quoteId refines rather than contradicts idempotentHint=false.

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?

Almost every sentence earns its place, and the lead sentence is front-loaded with the core contract. It is a single dense paragraph of long clauses, though; splitting the inputs-keying rules and the quote/idempotency rules into separate lines would improve scannability without losing content.

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?

For a costly, destructive, async tool with no output schema, it supplies everything an agent needs: the immediate return value (runId), how to observe progress, cost gating, retry safety, entry-node input rules, and when to route to a different tool entirely. The remaining parameters (preview, callbackUrl) are well documented in the schema itself.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 67% schema coverage and an opaque `inputs` object (additionalProperties: {}, no schema description), the description carries the critical semantics: keys are entry node ids, per-node-type value shapes (text, JSON value, overriding URL for File nodes), omission behavior, and the '' escape hatch. It also clarifies the quoteId/requestId relationship (requestId not needed with quoteId).

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?

Opens with a specific verb, resource and execution model: start a pipeline run in the background and return its runId immediately. It also names the exact siblings that share its problem space (get_run, estimate_run_cost, assemble_video), so an agent can slot it against them without reading their schemas.

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?

Gives explicit when-to-use branches: poll get_run for progress, call estimate_run_cost and get user acceptance before running a built/changed pipeline, and use assemble_video or edit_asset instead of re-running to add music, narration or captions. It even states a fallback behavior (ask the user what the entry node should say) when the request omits it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.