Skip to main content
Glama

Combine videos

combine_videos

Join existing video clips into ONE continuous video, in the order given — assemble a multi-shot sequence from clips already in the library (NOT to generate new footage). Pass 1–10 artifact ids (job:#0 handles, in play order). Clips are normalized (resolution/fps) and concatenated, removing the jump between mismatched clips. TRIM: to cut a clip before joining, pass an object { id, start, end } (or { id, start, duration }) in SECONDS instead of a bare id; or set max_clip_seconds to keep the first N seconds of EVERY clip (models often return a longer clip than asked — e.g. ~4s for a 3s request). One clip + a trim is a valid single-clip trim. Ranges auto-clamp to the real clip length. AUDIO: pass audio_id (a voiceover from generate kind "speech") and/or music_id (a bed from generate kind "music") to lay over the result. audio_mode:"replace" (default) makes the overlay(s) the ONLY soundtrack (clips' own audio muted); audio_mode:"mix" lays them OVER the clips' audio — set clip_volume (0–2, e.g. 0.2) to quiet the clips' own sound effects under a voiceover. Each overlay has its own gain (audio_volume / music_volume, 0–2; e.g. VO 1.0, music 0.15) and optional fades (audio_fade_in/out, music_fade_in/out, seconds). ducking:true auto-lowers the clips' audio + music WHILE the voiceover speaks and lets them recover in the gaps (sidechaincompress) — the cleanest way to keep a VO on top. Per clip: a video_ids object can carry its own volume (e.g. {id, volume:0.3}) to set that one clip's audio level. Single clip + audio_id = swap one video's audio. Output is free (no model runs). Unsure which ids or their order? call search_creations or read the Recent list in get_settings first. If you have not loaded it this session, call load_skill("combining-videos").

Input Schema

NameRequiredDescriptionDefault
duckingNo
audio_idNo
music_idNo
video_idsYes
audio_modeNo
project_idNoOpaque per-chat project id: "p-" plus 6 random letters and digits. Every chat is a new project. Mint one on your first emero call and pass that SAME id on every call in this chat. Never mint a second one in the same chat, even for a new topic, campaign or subject. Only when the user asks to continue an earlier project, reuse its id from get_emero_brain's project list.
clip_volumeNo
audio_volumeNo
music_volumeNo
project_nameNoShort human title for the project (2-5 words from the user request, e.g. "Perfume ad campaign"). Pass it on your first generate/ingest_url so the project is not left "Untitled". You may also rename at will later — pass an updated project_name (on a generate/ingest_url, or on set_settings with no other change) whenever the user asks, e.g. "call this project cats".
audio_fade_inNo
music_fade_inNo
audio_fade_outNo
music_fade_outNo
max_clip_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / project_id / description
      Previous value: -"Opaque per-chat project id. Mint one on your first emero action, pass that SAME id every call. One project per chat: NEVER mint a second for a new topic/campaign/subject/vibe — all stay in the one project; a new id is only for a new chat (server folds a stray id back in). A new chat the user says continues an earlier project reuses that project's id (from get_emero_brain's project list)."New value: +"Opaque per-chat project id: \"p-\" plus 6 random letters and digits. Every chat is a new project. Mint one on your first emero call and pass that SAME id on every call in this chat. Never mint a second one in the same chat, even for a new topic, campaign or subject. Only when the user asks to continue an earlier project, reuse its id from get_emero_brain's project list."
  2. First observed

TDQS

A4.9/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 richly: normalization to a common resolution/fps, concatenation, clamping of ranges, audio replacement vs. mixing, ducking via sidechain compression, per-clip volume, and the fact that output is free. It explains the effects of each mode rather than merely naming them.

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-loads purpose and usage, then organizes detail under TRIM and AUDIO headings. It is dense and long, but for a 15-parameter tool with low schema coverage almost every sentence adds needed semantics; a small amount of tightening is possible but not much.

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 output schema and low schema coverage, the description fills every gap an agent needs: id formats, ordering, trimming, per-clip audio, overlay mixing, ducking, and the no-cost output. Nothing essential for correct invocation appears missing.

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 description coverage is only 13%, so the description must compensate, and it does: it explains the video_ids string vs. trim-object shape, seconds units for start/end/duration, max_clip_seconds behavior, audio_id/music_id sources, audio_mode semantics, clip/audio/music volume ranges, fade units, and ducking. The remaining project_id/project_name params already carry thorough schema descriptions.

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 ('Join existing video clips into ONE continuous video') and explicitly excludes the sibling generate path ('NOT to generate new footage'). The scope and ordering constraint are clear enough to distinguish it from every sibling.

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 explicit routing: call search_creations or get_settings when ids or order are unknown, and load_skill('combining-videos') when the skill isn't loaded. Also clarifies the generate alternative is wrong for this task, so when/when-not is fully covered.

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.