Skip to main content
Glama
kvoltmer

Audionaut MCP Server

Set clip fades

clip_fades

Set a clip's fade-in and fade-out ramps, curve exponents, and edge offsets to create fades or centered crossfades, with values in bars, beats, seconds, or clocks.

Instructions

Sets the addressed clip's fade ramps and curve exponents (0.1-4, 0.5 = equal power). All four fade values are in unit (default bars) and 0 clears one. Each ramp has two edges measured inward from the clip edge: the fade-in runs from fade_in_start to fade_in after the clip start, the fade-out from fade_out to fade_out_end before the clip end, so a ramp lasts fade_in - fade_in_start (or fade_out - fade_out_end). A negative offset puts that edge outside the clip, playing source audio beyond it - e.g. fade_out 0.25 with fade_out_end -0.25 (seconds) is a 0.5 s ramp centred on the clip end, the outgoing half of a crossfade. Values are clamped against each other within the clip. The address must match exactly one clip.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNoTimeline position of the clip (exclusive with region)
unitNoUnit for positions (default bars; bars/beats are 1-based, seconds/clocks absolute)
trackNoTrack id
regionNoRegion name of the clip
fade_inNoWhere the fade-in ramp reaches full level, measured from the clip start; the ramp length only when fade_in_start is 0
projectYesPath to the .audium project package (absolute paths recommended)
fade_outNoWhere the fade-out ramp begins, measured back from the clip end; the ramp length only when fade_out_end is 0
fade_out_endNoWhere the fade-out ramp reaches silence, measured back from the clip end; negative = past the clip end
fade_in_curveNoFade-in curve exponent (0.1-4, 0.5 = equal power)
fade_in_startNoWhere the fade-in ramp begins, measured from the clip start; negative = before the clip start
fade_out_curveNoFade-out curve exponent (0.1-4, 0.5 = equal power)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.6.4
    • changedInput schema / properties / fade_in / description
      Previous value: -"Fade-in length"New value: +"Where the fade-in ramp reaches full level, measured from the clip start; the ramp length only when fade_in_start is 0"
    • changedInput schema / properties / fade_in_start / description
      Previous value: -"Fade-in ramp start offset from the clip start"New value: +"Where the fade-in ramp begins, measured from the clip start; negative = before the clip start"
    • changedInput schema / properties / fade_out / description
      Previous value: -"Fade-out length"New value: +"Where the fade-out ramp begins, measured back from the clip end; the ramp length only when fade_out_end is 0"
    • changedInput schema / properties / fade_out_end / description
      Previous value: -"Fade-out ramp end offset from the clip end"New value: +"Where the fade-out ramp reaches silence, measured back from the clip end; negative = past the clip end"
  2. First observedv0.2.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it explains clamping behavior ('Values are clamped against each other within the clip'), the address constraint ('must match exactly one clip'), and the logic of negative offsets placing edges outside the clip. However, it doesn't disclose what happens on failure (e.g., ambiguous address error), permissions, or whether changes are reversible.

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 operation, then the curve range, then unit/default, then the detailed edge semantics with a concrete example. The crossfade example is useful but slightly verbose; overall the structure is logical and each sentence earns its place except perhaps the redundant restatement of the ramp length formula.

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

Completeness4/5

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

Given 11 parameters, no annotations, and no output schema, the description covers the critical fade semantics, defaults, clearing behavior, and address requirement thoroughly. It doesn't explain return values (no output schema exists) or error conditions for address mismatches, but is otherwise complete for correct invocation.

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?

Despite 100% schema coverage, the description adds substantial meaning: it explains the relationship between fade_in and fade_in_start, fade_out and fade_out_end, how ramp length is derived, the meaning of negative offsets (playing source audio beyond the clip, crossfade example), default unit, and that 0 clears a fade. This goes well beyond the schema's per-field 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+resource (sets the addressed clip's fade ramps and curve exponents) and distinguishes itself from siblings like clip_gain and clip_speed by focusing exclusively on fade ramps. The scope is unambiguous.

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

Usage Guidelines3/5

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

The description explains the mechanics of fade parameters well but doesn't explicitly state when to use this tool versus alternatives (e.g., clip_gain for volume, clip_speed for time-stretching). Usage is implied by the operation described, but no exclusions or alternative-routing guidance is provided.

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