Skip to main content
Glama

video_composite_layers

Composite ordered image/video layers from a JSON spec with alpha, opacity, transforms, timing, masks, and blend modes. Validate and emit a deterministic layer plan before rendering.

Instructions

Composite ordered image/video layers from a JSON spec.

Supports explicit straight/premultiplied input alpha, opacity, positioning, transforms, timing windows, masks/mattes, allowlisted blend modes, rotation, and effect-noise routes to named layer/mask/mask-edge streams. Emits a deterministic layer-plan receipt; unsupported routes fail closed. File sources and masks must resolve inside the spec's directory.

Args: spec_path: Path to a composite-layers JSON spec. output_path: Optional destination media path. save_layer_plan: Optional JSON path for the resolved layer-plan receipt. dry_run: Validate and emit the layer plan without rendering media.

Input Schema

NameRequiredDescriptionDefault
dry_runNo
overwriteNoExplicitly allow replacing existing media. Existing non-media files are protected.
spec_pathYes
output_pathNo
save_layer_planNo

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

A3.8/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral burden and does well: it discloses deterministic layer-plan receipts, fail-closed handling of unsupported routes, and a path-resolution constraint requiring sources and masks to stay inside the spec directory. It does not discuss overwrite protection or permission requirements, but the core behavioral model is substantially explained.

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 purpose and then lists capabilities and arguments efficiently. The feature list is dense but relevant for a complex compositing tool, and the argument section adds practical clarity without excessive repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, spec-driven rendering tool with no annotations and low schema description coverage, the description supplies enough context about supported layer features, output behavior, and safety constraints. Since an output schema exists, it need not document return values, but it could be more complete with explicit sibling/tool-selection guidance.

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 description coverage is only 20%, so the description must compensate. It meaningfully explains spec_path, output_path, save_layer_plan, and dry_run beyond their bare schema types. The overwrite parameter is not mentioned in the description, though the schema itself contains a description for it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: compositing ordered image/video layers from a JSON spec. It distinguishes the operation from simple overlays by describing layers, masks, transforms, timing, and blend modes, but it does not explicitly differentiate itself from siblings such as video_composition_plan, video_overlay, or video_split_screen.

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?

Usage is implied by the phrase 'from a JSON spec' and by the listed capabilities, suggesting this tool is for spec-driven multi-layer compositing. However, it gives no explicit when-to-use or when-not-to-use guidance and does not name alternative tools for simpler overlays or composition planning.

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