Skip to main content
Glama

var2_join_videos

Stitch videos / images / audio into one mp4 on a 30fps timeline. Fractional seconds are supported and rounded to frames, not whole seconds; the plan returns timeline_frames and fps. For a VERIFIED duplicated shared endpoint between 30fps clips, shorten the preceding clip by exactly 1/30 second, preserve the next first frame, and use no transition. A shared reference image does not prove actual endpoints match or eliminate duplicate frames; this tool does not extract or compare frames. Never replace one-frame removal with an arbitrary 0.2–0.5 second trim. Continuous background audio spans the joined timeline. Two-pass: dry_run=true (default) returns a plan to review with the user; dry_run=false renders it. Poll with var2_check_join_status (NOT var2_get_video_result).

Input Schema

NameRequiredDescriptionDefault
nameNoOptional project name shown in the user's editor.
dry_runNoWhen true (default), returns the planned timeline + render-time estimate WITHOUT actually queuing the render, plus a `plan_id`. ALWAYS call with dry_run=true first, show the plan to the user, get explicit approval, then render by calling with ONLY {plan_id} — no other parameters needed. Renders take minutes-to-hours and use compute budget — never run without confirmation.
plan_idNoRender an approved plan exactly as shown: after user approval, call with ONLY {plan_id} — nothing else needed (dry_run defaults to render when plan_id is present). A jp_… id ALWAYS comes back HERE to START the render — it is a plan id, NOT a status id (status ids are plain UUIDs and go to var2_check_join_status). {plan_id, dry_run:true} re-displays the stored plan. If any parameter changed after the dry-run, resend full args instead.
segmentsYesOrdered list of clips on the timeline. ALWAYS ask the user about the order before calling — the order matters and cannot be changed after rendering starts.
resolutionYesREQUIRED — always ask the user. 1080p renders roughly 2× longer than 720p but produces a sharper output.
aspect_ratioYesREQUIRED — always ask the user which one they want. 16:9 = landscape (YouTube/desktop), 9:16 = portrait (TikTok/Reels/Shorts), 1:1 = square (Instagram feed).
background_audio_urlNoOptional separate audio track that spans the whole video (storage/signed URL, var2 share link, or placeholder_id — resolved server-side). Ask the user if they want background music.
background_audio_volumeNo
video_audio_when_stackedNoHow to handle the video's native audio when an audio source is layered on top (inline audio segments OR background_audio_url). When the timeline stacks video + audio, ALWAYS ask the user — and recommend `mute` as the first option (cleanest result, no clashing tracks). `reduce` keeps video audio at 0.2× under the music. `keep` plays both at full volume (usually clashes).
background_audio_placeholder_idNoSTRONGLY RECOMMENDED whenever `background_audio_url` is set. The placeholder_id of the asset behind that URL (e.g. the id returned by var2_upload_asset). Without it the editor opens the saved project with an empty background-audio clip — no waveform, no playback in preview — even though the rendered mp4 mixes the audio correctly. The server auto-extracts var2 UUIDs from var2.ai share-page URLs and Supabase storage paths when possible.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations carry only a title, so the description bears the full behavioral burden and does so: frame rounding (not whole seconds), no server-side frame extraction or comparison, renders take minutes-to-hours and consume compute budget, plan returns timeline_frames/fps, and plan_id lifecycle (jp_ prefix, resend full args if params changed). These are exactly the traits an agent cannot infer elsewhere.

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?

Front-loaded with the core action and the two-pass contract, and most sentences earn their place. It is dense and long, and the duplicate-endpoint guidance is somewhat niche for the opening paragraph, but nothing is redundant 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?

For a 10-parameter, multi-stage rendering tool with no output schema and no meaningful annotations, the description covers the full lifecycle: planning, review, approval, render, and polling handoff, plus what the plan returns. An agent has everything needed to invoke it correctly end-to-end.

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 already 90%, so the baseline is 3. The description nonetheless adds real meaning beyond the schema: the plan_id-vs-status-id distinction, the 'call with ONLY {plan_id}' contract, and the 1/30s vs arbitrary-trim rule for duration_seconds. It stops short of covering every parameter (e.g. background_audio_volume), hence 4 rather than 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?

States a specific verb and resource ('Stitch videos / images / audio into one mp4 on a 30fps timeline'), and the 30fps timeline detail immediately distinguishes it from generic render/mux tools. The scope is unambiguous against siblings like var2_render_timeline or var2_create_video.

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?

Explicitly prescribes the two-pass workflow (dry_run=true first, review with user, then dry_run=false), states the default, and names the correct polling tool (var2_check_join_status, NOT var2_get_video_result). It also gives a concrete when-to-use rule for the duplicate-endpoint fix. This is close to exhaustive routing guidance.

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.

Resources