Skip to main content
Glama

video_workflow_render

Validates a workflow job-spec, runs allowlisted media operations sequentially, and returns a provenance receipt; render variants or resume failed jobs from kept intermediates.

Instructions

Execute an agent workflow job-spec and return a provenance receipt.

Validates the spec first (fail-closed), then runs each allowlisted op (probe|trim|resize|convert|merge|add_text|composite_layers) SEQUENTIALLY in spec order via the backing engine functions. Intermediates are written to a per-run @work directory unique to this invocation and cleaned on success (kept on failure); final media lands at the declared @outputs paths.

Batch variants: pass variant=<id> to render one declared variant (its overrides patch the shared steps/outputs, and the single @outputs path is auto-named with the variant id so N variants emit N distinct outputs); the receipt records workflow.variant. Pass all_variants=True to render EVERY declared variant in turn and return a workflow_batch summary (one receipt per variant, each into its own @work dir); use save_receipt_dir to also write each variant's receipt to <dir>/<variant>.json. variant and all_variants are mutually exclusive. Pass keep_intermediates=True to retain @work intermediates even on success (recorded as the keep-intermediates cleanup policy).

Pass resume_receipt (a prior render receipt from a job that failed with its intermediates kept) to RESUME: the current spec_hash must equal the receipt's (else fail-closed resume_spec_mismatch) AND, for a variant, the receipt's variant must match (else resume_variant_mismatch); each step whose recorded status is completed AND whose recorded input hashes still match AND whose recorded output file still exists and re-hashes to the recorded hash is SKIPPED, and the first step failing any check plus everything after it re-runs.

Returns a workflow receipt (receipt_kind: "workflow") capturing tool + FFmpeg versions, the spec hash, per-source probes/hashes, per-step status with real sha256 hashes of every consumed input and produced output, the cleanup manifest, and the determinism-scope caveat. On the first failing step it fails closed: the failure is recorded on the receipt (still written to save_receipt when given) and surfaced as a structured error.

Args: spec_path: Absolute path to the workflow job-spec JSON file. resume_receipt: Optional path to a prior render receipt to resume from. save_receipt: Optional path to write the workflow receipt as JSON. keep_intermediates: Retain @work intermediates even on success. variant: Optional declared variant id to render a single variant. all_variants: Render every declared variant and return a batch summary. save_receipt_dir: With all_variants, directory for per-variant receipts.

Input Schema

NameRequiredDescriptionDefault
variantNo
overwriteNoExplicitly allow replacing existing media. Existing non-media files are protected.
spec_pathYes
all_variantsNo
save_receiptNo
resume_receiptNo
save_receipt_dirNo
keep_intermediatesNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.16.4
    • addedInput schema / properties / overwrite
      Added value: +{
      +  "default": false,
      +  "description": "Explicitly allow replacing existing media. Existing non-media files are protected.",
      +  "title": "Overwrite",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changedv1.16.0
    • addedInput schema / additionalProperties
      Added value: +false
  3. Addedv1.6.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: fail-closed validation, sequential execution, temporary @work cleanup on success versus retention on failure, final @outputs behavior, batch semantics, resume hash checks, receipt contents, cleanup manifest, and determinism caveat are all disclosed.

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 description is front-loaded with the core execute-and-receipt purpose, then organized into batch, resume, and Args sections. It is long and dense, but for an 8-parameter workflow engine most detail is functional; a few parenthetical clauses could be tightened.

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 complex tool with no annotations and low schema description coverage, the description supplies the execution model, failure behavior, resume logic, parameter modes, and receipt contents. An output schema exists, but the description still gives enough context for an agent to invoke it correctly.

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?

Schema coverage is only 13%, but the description compensates for 7 of 8 parameters with rich semantics: absolute spec_path, resume_receipt matching rules, save_receipt, keep_intermediates, variant overrides, all_variants batching, and save_receipt_dir usage. The only omitted parameter, overwrite, is already described 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 description states a specific action: execute an agent workflow job-spec and return a provenance receipt. It distinguishes execution from validation/planning siblings by explaining that it validates first, then runs each allowlisted op sequentially and writes final media to declared outputs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives detailed operational guidance for variant, all_variants, resume_receipt, and keep_intermediates, including mutual exclusivity and resume conditions. However, it never states when to choose this tool over siblings like video_workflow_validate, video_workflow_plan, or individual op tools, nor when not to use it.

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

Deploy Server

Other Tools