cuttingfloor

Add effect

filter.add

Idempotent

Apply an effect to a clip, every clip on a track, or the whole timeline: picture effects (colour, LUT, blur, vignette, chroma key, glitch, denoise and more) on video, sound effects (EQ, compressor, noise_reduction, voice_denoise, pitch and more) on audio. Order matters: effects run in the order added (a track's before a clip's own). Picture numbers take keyframes, except glitch, denoise and chroma_key tolerance; sound params are constants. A wrong name or param is refused with the full list, ranges, units and defaults (also at video://catalog/effects); timeline.get shows every param applied. Returns its id as clip_id. Returns the edit result (see the server instructions).

Input Schema

Name	Required	Description	Default
`name`	Yes
`params`	No	The effect's own params; any left out take their defaults. A wrong one is refused with the effect's params, ranges, units and defaults
`clip_id`	No	Apply to one clip (or an adjustment clip)
`preview`	No	inline: image in the result; link: URI that renders on read; none	link
`timeline`	No	Or true for the whole picture or mix
`track_id`	No	Or to every clip on a track
`timeline_id`	Yes	Timeline handle; every edit returns a new one

Output Schema

Name	Required	Description
`parent`	Yes	Timeline handle; every edit returns a new one
`changed`	Yes
`clip_id`	No
`preview`	Yes
`clip_ids`	No
`track_id`	No
`warnings`	Yes
`timeline_id`	Yes	Timeline handle; every edit returns a new one

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 1, 2026

removedInput schema / properties / name / description

Removed value: -"An effect from video://catalog/effects"

addedInput schema / properties / name / enum

Added value: +[
+  "brightness_contrast",
+  "saturation",
+  "exposure",
+  "temperature",
+  "hue",
+  "vibrance",
+  "curves",
+  "lut",
+  "grayscale",
+  "sepia",
+  "invert",
+  "blur",
+  "sharpen",
+  "vignette",
+  "grain",
+  "chromatic_aberration",
+  "pixelate",
+  "glitch",
+  "denoise",
+  "chroma_key",
+  "equalizer",
+  "compressor",
+  "noise_reduction",
+  "voice_denoise",
+  "de_esser",
+  "dialogue_enhance",
+  "reverb",
+  "echo",
+  "pitch",
+  "highpass",
+  "lowpass",
+  "telephone",
+  "dereverb",
+  "lens_correction",
+  "directional_blur",
+  "channels"
+]

removedInput schema / properties / name / maxLength
```
Removed value: -60
```
removedInput schema / properties / name / minLength
```
Removed value: -1
```

changedInput schema / properties / params / description

Previous value: -"As the catalogue lists them"New value: +"The effect's own params; any left out take their defaults. A wrong one is refused with the effect's params, ranges, units and defaults"

First observedOct 25, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Adds a lot beyond the annotations: ordering semantics, that picture params accept keyframes except glitch/denoise/chroma_key tolerance, that sound params are constants, and that invalid names/params are rejected with the full list, ranges, units and defaults (also at video://catalog/effects). One soft tension with idempotentHint=true: 'effects run in the order added' implies calling twice stacks two effects, so repeated invocation is not state-neutral, and the description never reconciles this.

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?

A single dense paragraph, front-loaded with what gets the effect and where; every clause carries information. It is long, but the length is earned by the number of distinct behavioral rules packed in, with few wasted words.

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?

Covers targeting, ordering, keyframe limits, error recovery via the effects catalog, the returned id, and defers return-shape detail to the server instructions (an output schema exists). The only gap is the idempotency/stacking question an agent would face when re-applying an effect.

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 coverage is 86%, so the schema already documents nearly all parameters; the description mostly reinforces it. It does add genuinely extra meaning (which effect families take keyframes vs. constant params, that params omitted take defaults, the refusal-with-details error contract), but it adds no format/syntax detail for the params object itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Apply an effect') plus the three possible targets (clip, all clips on a track, whole timeline) and enumerates the effect families (colour, LUT, blur, EQ, compressor...). The purpose is unambiguous, but it never names the adjacent filter.set / filter.remove siblings, so the agent must infer that this tool only creates effects and does not modify them.

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?

Gives concrete selection rules for each targeting parameter ('Apply to one clip', 'or true for the whole picture or mix', 'or to every clip on a track'), plus an evaluation-order rule (a track's effects run before a clip's own). It does not say when to use filter.set or filter.remove instead, which is the main missing piece.

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

All cuttingfloor 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.