Clipia

compose_video

Stitch 2–20 finished video scenes into ONE final clip server-side (scenes are normalized to a common frame/fps, concatenated, optional soundtrack replaces scene audio). Pass request_id of your COMPLETED video generations (or media.clipia.ai URLs). Returns request_id (cmp_*) — poll with wait_generation until COMPLETED, then output.video.url is the final mp4. Typical full-video flow: generate_scenario → generate_video per scene → compose_video.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "scenes": "<scenes>"
    },
    "name": "compose_video"
  }
}

Input Schema

Name	Required	Description	Default
`scenes`	Yes	Scenes in playback order. Each item: {request_id} of a COMPLETED video generation (or a previous compose), or {video_url} from media.clipia.ai. Optional duration_seconds trims (shorter) or freeze-extends (longer) the scene.
`audio_url`	No	Optional: soundtrack https URL on media.clipia.ai (alternative to audio_request_id).
`normalize`	No	Re-encode scenes to a common format before concat (keep true unless all scenes come from the same model with identical settings).
`subtitles`	No	Optional burned-in subtitles (styled, bottom-centered). Timings are relative to the FINAL stitched video.
`resolution`	No		1080p
`aspect_ratio`	No	Frame of the final video; scenes are letterboxed to fit.	9:16
`voiceover_url`	No	Optional: narration https URL on media.clipia.ai (alternative to voiceover_request_id).
`idempotency_key`	No	Stable key for a safe retry of this exact compose request. Reuse the same key after a transport failure.
`audio_request_id`	No	Optional: a COMPLETED audio/music generation to use as the soundtrack (replaces scene audio, loudness-normalized, fade-out).
`voiceover_request_id`	No	Optional: a COMPLETED audio generation used as narration — mixed OVER the soundtrack (music ducks to 25%) or over scene audio (ducks to 30%).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only tell the agent this is a non-read-only, non-destructive, non-idempotent call. The description adds the async contract (returns a cmp_* request_id that must be polled with wait_generation, final mp4 at output.video.url) and the mutation semantics (normalization to a common frame/fps, letterboxing, soundtrack replacing scene audio, ducking). That is substantial behavior beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the operation and its output contract, then the input requirement, then the pipeline context. No sentence is redundant and no padding is present.

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 mutation with no output schema, the description still covers the return value, the polling requirement, and the overall pipeline placement. An agent can construct a correct call and follow up without needing to open any sibling definition.

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 coverage is 90%, so the schema already carries most parameter documentation. The description still adds value by stating the 2–20 scene bound, that each entry must reference a COMPLETED generation and is concatenated in playback order, and that the soundtrack replaces scene audio rather than mixing with it. Optional params (subtitles, resolution, idempotency_key) get no treatment in the description, which keeps this from 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?

Opening sentence states a specific verb (stitch), an explicit input scope (2–20 finished video scenes) and an explicit output (ONE final clip), plus the server-side qualifier. This clearly separates it from generate_video (single scene) and generate_audio among siblings.

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?

States the precondition that inputs must be COMPLETED video generations or media.clipia.ai URLs, and gives the canonical alternative-free workflow: generate_scenario → generate_video per scene → compose_video. It also names wait_generation as the follow-up, so the agent knows exactly where this sits in the pipeline.

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

All Clipia tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.