Skip to main content
Glama
wave-av

WAVE MCP Server

Official
by wave-av

wave_create_clip

Create a clip from a recording by providing the recording ID and start time. Optionally set end time, duration, dimensions, quality, and output formats.

Instructions

Create a clip from a recording (POST /v1/clips). source is a recording ID; in and, optionally, out/duration are time strings like "5s" or "2m"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inYesClip start offset, a time string like "5s" or "2m" (0-10m)
fitNoResize fit mode (default: contain)
outNoClip end offset, a time string like "35s". Omit if using `duration`
widthNoOutput width in px (10-2000)
heightNoOutput height in px (10-2000)
sourceYesThe recording ID to clip from
formatsNoOutput formats to generate (default: [mp4])
qualityNoOutput quality lane (default: 720p)
durationNoClip length, a time string like "30s" (1s-60s). Omit if using `out`
visibilityNoStorage/delivery visibility (default: private)
spritesheet_framesNoFrame count for spritesheet output (1-120, default: 30)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed18 schema fields changedv0.3.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / duration
      Added value: +{
      +  "description": "Clip length, a time string like \"30s\" (1s-60s). Omit if using `out`",
      +  "type": "string"
      +}
    • removedInput schema / properties / end_time
      Removed value: -{
      -  "description": "Clip end time in seconds",
      -  "minimum": 0,
      -  "type": "number"
      -}
    • removedInput schema / properties / export_to
      Removed value: -{
      -  "description": "Social platforms to auto-export to",
      -  "items": {
      -    "enum": [
      -      "tiktok",
      -      "youtube_shorts",
      -      "instagram_reels",
      -      "twitter"
      -    ],
      -    "type": "string"
      -  },
      -  "type": "array"
      -}
    • addedInput schema / properties / fit
      Added value: +{
      +  "description": "Resize fit mode (default: contain)",
      +  "enum": [
      +    "contain",
      +    "cover",
      +    "scale-down"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / formats
      Added value: +{
      +  "description": "Output formats to generate (default: [mp4])",
      +  "items": {
      +    "enum": [
      +      "mp4",
      +      "spritesheet",
      +      "m4a",
      +      "frame"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / height
      Added value: +{
      +  "description": "Output height in px (10-2000)",
      +  "maximum": 2000,
      +  "minimum": 10,
      +  "type": "integer"
      +}
    • addedInput schema / properties / in
      Added value: +{
      +  "description": "Clip start offset, a time string like \"5s\" or \"2m\" (0-10m)",
      +  "type": "string"
      +}
    • addedInput schema / properties / out
      Added value: +{
      +  "description": "Clip end offset, a time string like \"35s\". Omit if using `duration`",
      +  "type": "string"
      +}
    • addedInput schema / properties / quality
      Added value: +{
      +  "description": "Output quality lane (default: 720p)",
      +  "enum": [
      +    "720p",
      +    "1080p",
      +    "4k"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / source
      Added value: +{
      +  "description": "The recording ID to clip from",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / spritesheet_frames
      Added value: +{
      +  "description": "Frame count for spritesheet output (1-120, default: 30)",
      +  "maximum": 120,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • removedInput schema / properties / start_time
      Removed value: -{
      -  "description": "Clip start time in seconds",
      -  "minimum": 0,
      -  "type": "number"
      -}
    • removedInput schema / properties / stream_id
      Removed value: -{
      -  "description": "The stream ID to clip from",
      -  "format": "uuid",
      -  "type": "string"
      -}
    • removedInput schema / properties / title
      Removed value: -{
      -  "description": "Clip title",
      -  "maxLength": 255,
      -  "type": "string"
      -}
    • addedInput schema / properties / visibility
      Added value: +{
      +  "description": "Storage/delivery visibility (default: private)",
      +  "enum": [
      +    "public",
      +    "private"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / width
      Added value: +{
      +  "description": "Output width in px (10-2000)",
      +  "maximum": 2000,
      +  "minimum": 10,
      +  "type": "integer"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "stream_id",
      -  "start_time",
      -  "end_time"
      -]New value: +[
      +  "source",
      +  "in"
      +]
  2. First observedv0.1.5

TDQS

A3.7/5.0
Behavior2/5

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Create a clip' and gives parameter hints; it does not mention whether processing is asynchronous, what the response contains, side effects, or failure modes. This is a significant gap for a mutating POST operation.

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?

The description is two sentences with no wasted words. It front-loads the action and endpoint, then immediately clarifies the key parameter semantics. It is compact, readable, and easy for an agent to parse.

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

Completeness3/5

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

This is an 11-parameter tool with no annotations and no output schema. The rich schema covers invocation inputs well, but the description provides no information about return values, processing behavior, or post-invocation expectations. It is minimally viable but leaves meaningful gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains all parameters. The description adds the time-string pattern and notes that `out`/`duration` are optional, but these details are largely repeated in the schema descriptions. No new parameter semantics are provided beyond the schema.

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?

The description states a specific action ('Create a clip from a recording') and includes the exact endpoint (POST /v1/clips). It clearly names the input resource (recording) and the output object (clip), making its purpose unambiguous and distinct from sibling stream/production tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: use this tool to create clips from an existing recording ID, with `in` and optionally `out`/`duration` as time strings. It does not explicitly mention when-not-to-use or alternatives, but no sibling clip tool exists, so the usage context is sufficient.

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