Skip to main content
Glama

VAR2.ai

by ai.var2
OverviewDiscussionsAdmin

var2_trim_audio

Cut or SPLIT AUDIO (a song / track / recording) by time — the only tool for that. Triggers: "cut seconds X to Y out of my song", "split this track into pieces", "keep only 0:12–0:40", "first 45 seconds", "shorten to 60s for pruna-avatar / heygen-avatar-iv". Modes: one range (start/end); explicit segments in ONE call (segments=[{start_seconds,end_seconds,id?},…]); SMART lyrics split (lyrics_timestamps + target/min/max_segment_seconds — never cuts mid-word, prefers line/chorus ends). Returns NEW asset(s) (url + placeholder_id); original untouched. audio_url: storage URL, var2 share link, or placeholder_id. Making new/longer music (extend, replace a section) → var2_create_audio; voice-overs → var2_create_dialog.

Input Schema

NameRequiredDescriptionDefault
nameNoOptional title for the asset library (single-cut mode).
segmentsNoBatch split: several cuts from the same track in ONE call, e.g. [{start_seconds:0,end_seconds:8},{start_seconds:8,end_seconds:16}]. Each returns its own asset.
audio_urlYesThe track to cut from — storage URL, var2 share link (www.var2.ai/music/<id>), or placeholder_id (auto-resolved).
end_secondsNoSingle cut: end, in seconds. Pass this OR duration_seconds.
start_secondsNoSingle cut: start, in seconds. Default 0.
duration_secondsNoSingle cut: length, in seconds. Pass this OR end_seconds.
lyrics_timestampsNoSmart split: word-level timestamps [{word,start,end,break?}] (break ∈ line|bar|chorus on a line's LAST word). The server picks cuts that NEVER land mid-word and prefer line/chorus ends, sized by target/min/max_segment_seconds. Returns scene_1..N assets.
max_segment_secondsNoHARD ceiling in every mode — never exceeded. Smart split cuts INSIDE the limit (mid-verse at a word end if a verse overshoots); explicit/single ranges that overshoot are rejected. Default 60 for lyrics mode (pruna-avatar / heygen-avatar-iv audio cap).
min_segment_secondsNoSmart split: hard minimum. Default 4.
target_segment_secondsNoSmart split: preferred segment length. Default 8.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only carry a title, so the description bears the burden and delivers key behavior: it returns NEW asset(s) with url + placeholder_id while the 'original untouched' (non-destructive). It does not mention auth needs, rate limits, or failure handling, but the non-destructive return contract is the most important trait for this operation.

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 purpose and the exclusivity claim, then triggers, then modes, then routing — a logical order with no filler. It is dense (a long compound paragraph with many semicolon clauses), which slightly trades readability for completeness.

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 10 parameters, no output schema, and no annotations beyond a title, the description still covers return shape (url + placeholder_id), non-destructive behavior, all three modes, segment caps/defaults, and sibling routing. Nothing an agent needs to invoke 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% (baseline 3), yet the description adds real meaning beyond the schema: the interplay of start/end vs duration, the SMART lyrics-split guarantee ('never cuts mid-word, prefers line/chorus ends'), and mode defaults. It goes beyond restating field docs.

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(s) and resource ('Cut or SPLIT AUDIO (a song / track / recording) by time') and explicitly claims exclusivity ('the only tool for that'). It also names the sibling tools it is not (var2_create_audio, var2_create_dialog) so an agent can route without opening schemas.

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?

Provides concrete trigger phrases ('cut seconds X to Y out of my song', 'first 45 seconds'), enumerates the three operating modes, and explicitly routes alternatives: extend/replace music → var2_create_audio, voice-overs → var2_create_dialog. When-to-use and when-not-to-use are both covered.

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

All VAR2.ai toolsInspect
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.

Resources