Skip to main content
Glama

Treza

by io.github.treza-labs
OverviewDiscussionsAdmin

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 and wait for the person to accept the price. 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.

Input Schema

TableJSON 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.
pipelineIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare non-readonly, destructive, openWorld, non-idempotent, and the description adds substantive context beyond them: runs consume credits, invalid keys are refused before charging, omitted entry nodes fall back to canvas values, empty nodes are refused, and the tool starts in the background. Nothing here contradicts the annotations.

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?

The core action and async return are front-loaded in the first sentence, and each subsequent sentence carries distinct operational guidance. It is dense and long, with one sprawling multi-clause sentence about alternatives, but almost nothing is filler.

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?

Despite no output schema and a nested inputs object, the description explains the return (runId), the polling path, credit cost, refusal conditions, and the cost-estimation prerequisite. An agent has everything needed to invoke it correctly and route follow-ups.

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 only 33% schema description coverage, the description compensates thoroughly: inputs is keyed by entry node id, Text Input takes text, HTTP Payload takes JSON, File takes a URL overriding the canvas file, omission falls back to the saved value, empty nodes are refused, and "" deliberately blanks. The preview parameter's odd return semantics are covered in the schema.

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 first sentence names a specific verb and resource ('Start a pipeline run') and states the immediate return value ('return its runId immediately'), distinguishing it from synchronous siblings. It further differentiates itself by routing polling to get_run and pre-flight costing to estimate_run_cost.

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?

Explicit when-to-use and when-not-to-use guidance: poll get_run for progress, call estimate_run_cost before running a changed pipeline, and use assemble_video or edit_asset instead of re-running to add music/captions. It also tells the agent to ask the user when required input content is missing.

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

All Treza toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources