Skip to main content
Glama
ronak-create

FableCut

by ronak-create
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

fablecut_patch_project

Apply targeted edits to a FableCut project without re-sending the whole document, saving tokens and merging changes safely.

Instructions

Apply targeted edits to the FableCut project WITHOUT round-tripping the whole document — PREFER THIS over get+set for every edit (it is ~10-100x cheaper in tokens and merge-safe by design: it re-reads the latest document from disk, applies your ops in order, bumps revision once, saves atomically). Ops: {op:'addClip', clip:{…}} (id auto-generated if omitted) · {op:'updateClip', id, set:{…}} · {op:'removeClip', id} · {op:'addMedia', media:{…}} · {op:'removeMedia', id} · {op:'setProject', set:{name|width|height|fps|background|markers|disabledTracks|lockedTracks|untargetedTracks|encodeProfile|master}} (markers = the full list [{t, label?, color?}], color: gold|red|orange|green|cyan|blue|purple|pink; master = {gain}, the master fader in dB) · {op:'setTrack', id:'A1', set:{gain?, pan?, out?}} (audio-track fader in dB −60…+12, pan −1…1, out = a submix bus id or 'master'; null or 0 resets) · {op:'setBus', id:'B1', set:{name?, gain?, pan?, mute?}} (submix bus, created if missing; route tracks into it with setTrack out) · {op:'removeBus', id} · {op:'setFx', target:'clip'|'track'|'bus'|'master', id?, preset?:'podcast'|… OR fx:[{type,…params}], append?:true} (audio effects — validated; presets: clean-voice, podcast, radio, deep-voice, telephone, cinematic, wide, muffled; fx:null clears; on a clip it applies to its linked stems too) · {op:'setFxKeys', target, id?, index?|type?, param, keys:[{t, v, ease?}]|null} (automate one effect parameter: t is clip-local for a clip's effects, timeline seconds otherwise; see the 'Audio mix' docs section). TIMELINE EDITS — the editor's own split / ripple / trim code, so linked stems, track targeting (untargetedTracks) and locks behave exactly as in the UI; times in seconds: {op:'split', at, ids?} (no ids: every targeted track) · {op:'rippleDelete', ids} (later clips close the hole) · {op:'closeGap', at} · {op:'lift'|'extract', from?, to?} (remove a range; extract closes it; default = project inPoint/outPoint, which then clear) · {op:'insert'|'overwrite', mediaId, at, in?, duration?} (three-point edit: insert pushes later clips right, overwrite replaces what is there; a video brings one audio stem per channel) · {op:'rippleTrim'|'roll', id, side:'in'|'out', delta} · {op:'slip'|'slide', id, delta} (clamped to the media; the note says what was applied) · {op:'crossfade', ids? | at, duration?} (constant-power audio crossfade, borrowing handles from both sides). Any of these takes tracks:[…] to target lanes for that op only. setProject also takes inPoint / outPoint. updateClip merge rules: top-level keys are replaced (keyframes/transitionIn/transitionOut wholesale), props merges key-by-key, and setting any key to null deletes it. LOCKS: the user can lock clips (locked:true) and tracks (lockedTracks); updateClip / removeClip on a locked clip — or on a clip linked to one — and addClip onto a locked track are refused. Leave locked material alone; only if the user asked you to change it, pass force:true on that op (or unlock first: updateClip set:{locked:null}, which is always allowed). All-or-nothing: an invalid op aborts the whole patch unsaved.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opsYesEdit operations, applied in order (see tool description for shapes). Any op may carry force:true to override a lock the user set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.9.0
    • changedInput schema / properties / ops / description
      Previous value: -"Edit operations, applied in order (see tool description for shapes)"New value: +"Edit operations, applied in order (see tool description for shapes). Any op may carry force:true to override a lock the user set."
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it re-reads the latest document from disk, applies ops in order, bumps revision once, saves atomically, aborts the whole patch on an invalid op, and refuses edits on locked clips/tracks unless force:true. It also documents updateClip merge rules (top-level replaced, props merged key-by-key, null deletes).

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?

The front-loaded first clause delivers the core guidance and the price/comparison rationale immediately, and the volume of op documentation is largely justified by the tool's complexity. However, the remainder is a single dense run-on paragraph of ·-separated fragments rather than a scannable structure, which makes it harder to parse than necessary.

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 complex multi-op patch tool with no output schema and no annotations, the description covers transactional behavior, lock semantics, merge rules, op enumeration, and even a pointer to the 'Audio mix' docs for setFxKeys. Nothing an agent needs to invoke it correctly appears to be missing.

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?

The input schema only has an opaque 'ops' array whose own description defers to the tool description ('see tool description for shapes'). The description fully compensates, enumerating every op shape with field-level detail (e.g., gain ranges −60…+12, pan −1…1, color enum values, easing, three-point edit semantics).

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 and resource ('Apply targeted edits to the FableCut project') and explicitly distinguishes itself from the get+set siblings by naming the cheaper, merge-safe alternative. An agent can identify the tool's role without reading any schema.

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?

Explicitly says 'PREFER THIS over get+set for every edit' and quantifies why (~10-100x cheaper, merge-safe). It also gives clear when-to/when-not guidance around locked material ('Leave locked material alone; only if the user asked you to change it, pass force:true').

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

Deploy Server

Other Tools