Skip to main content
Glama

Render Composition

clipform_render_composition
Destructive

Render a specialised video composition to MP4 or PNG - custom animated visuals that clipform_generate_video can't provide, such as geography animations or designed motion graphics. Available composition names and their required input props schemas come from clipform_list_compositions.

For narrated Ken Burns slideshows from images, use clipform_generate_video instead. Output formats: mp4 (H.264, best for social media) or png (single frame). Returns a public URL when complete.

For multi-render builds (e.g. one clip per quiz question), pass everything in ONE call via items (max 10): all renders fire in parallel and you get one job ID each - then collect the URLs in a single clipform_check_render call with job_ids. Single render: pass compositionId/inputProps at the top level (wait: true blocks and returns the URL; wait: false returns a job ID).

Choosing a render tool: for a recognisable form/quiz beat (guess-the-city, this-or-that, mystery reveal, multiple choice, photo montage...) reach for a video template first (clipform_list_video_templates + clipform_render_video_template) - it is a one-call recipe. Use clipform_generate_video for a narrated or audio-synced media montage (images/clips timed to a voice track). Use clipform_render_composition only when neither fits and you need a custom layer stack. A render for a form node is not done until it is attached to that node. Pass node_id (and form_id) so the completed render attaches itself automatically - do not poll clipform_check_render to completion or manually chain clipform_upload_media_asset + clipform_attach_node_media; fire the render and move on. In batch mode, set node_id per item (see items) and form_id once at the top level.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNoSingle render only: true (default) blocks until the render is ready and returns its URL; false returns a job ID for clipform_check_render. Batch items always run fire-and-poll.
itemsNoBatch mode: multiple renders in one call. All fire in parallel; returns one job ID per item - collect with clipform_check_render (job_ids). Use this whenever rendering more than one clip.
contextYesDescribe the user's underlying goal in one sentence - not the tool you're calling.
form_idNoThe form UUID - required when node_id is set (single render) or any item sets node_id (batch).
node_idNoSingle render only: form node to attach this render to automatically once it completes. Requires form_id. For batch mode, set node_id per item instead.
captionsNoSingle render only: word-level captions from clipform_generate_tts, carried onto the attached media asset. Only used when node_id is set. For batch mode, set captions per item instead.
inputPropsNoSingle render: props object matching the composition's schema from clipform_list_compositions. Validated STRICTLY - unknown or missing props fail with the schema in the error, nothing renders silently with defaults. For map compositions (Map), wide shots (camera.zoom < 9) may round lat/lng to 1 decimal place to improve cache hit rates; close shots and pin drops should keep full precision — the pin lands exactly on `target`.
outputFormatNoSingle render: output format (default: mp4)mp4
compositionIdNoSingle render: the composition ID. Call clipform_list_compositions to see available options (e.g. 'Slideshow', 'Map', 'Grid'). Use items instead for multiple renders.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobsYesOne entry per render (single or batch)

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this as non-read-only, idempotent=false, and destructive, and the description adds rich behavioral context: strict inputProps validation failing loudly, map precision rounding at wide zoom, wait:true blocking vs wait:false returning a job ID, parallel batch execution, auto-attachment to nodes, and explicit 'do not poll... manually chain' guidance. No statement 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 description is long but front-loaded with purpose and organized into distinct concerns: purpose, alternatives, batch vs single, tool hierarchy, and node attachment. Every block earns its place, though a few passages duplicate the input schema's property descriptions and could be trimmed.

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?

With nine parameters, nested batch items, output formats, sibling render tools, and attachment side effects, the description covers all invocation-critical decisions: which tool to choose, how to batch, how to wait/collect results, and how to ensure renders attach to nodes. Nothing needed to call it correctly is missing.

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 100%, so the baseline is 3; the description goes above that by clarifying the wait/block semantics, the batch items max of 10, node_id/form_id auto-attachment requirements, and output format implications. It still repeats some schema content (e.g., map precision and captions provenance), so it is not flawless enough for a 5.

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?

Description opens with a specific verb+resource: 'Render a specialised video composition to MP4 or PNG', and distinguishes it from clipform_generate_video with examples (geography animations, motion graphics). It later names the exact alternatives, making the tool's identity unmistakable.

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 an explicit routing hierarchy: use clipform_render_video_template for quiz beats, clipform_generate_video for narrated montages, and this tool only when neither fits. It also specifies when to use batch vs single mode and instructs to pass node_id for auto-attachment rather than polling or chaining upload/attach calls.

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.

TDQS

A3.9/5.0
Disambiguation3/5

Most form/node CRUD tools are clearly distinct, but the render/generate trio (generate_video, render_video_template, render_composition) and get_responses vs get_results can be confused by name alone. The descriptions include strong disambiguation guidance, so the overlap is manageable but still present.

Naming Consistency4/5

The vast majority of tools follow a consistent clipform_verb_noun snake_case pattern, with create/get/update/delete/list used predictably. Minor deviations include get_more_tools lacking the clipform_ prefix and whoami not matching the verb_noun convention.

Tool Count2/5

At 34 tools, this is above the range where a toolset feels well-scoped, and several entries are auxiliary or internal (whoami, log_generation, get_more_tools, search_news). The domain is broad, but the surface could be consolidated without losing core capabilities.

Completeness4/5

The set covers form and node lifecycle, media upload/attachment, logic wiring, publishing, responses/results, and content generation (TTS, video, music, stock media). Minor gaps remain, such as no conditional branching in set_logic and no general media-library listing tool.