ChatCut

edit_track

Manage tracks: list | create | update | delete | tighten.

list: current track order with stable ids and aliases (read-only). Use it to refresh aliases before another edit.
create: json {"trackType":"video"|"audio"}, optional "count", "order" (zero-based position), "role", "name", "audioRouting". Video V1 (lowest order) is the back layer and larger V aliases render on top; audio is inverted, A1 is the top lane. New tracks default after existing ones. Use the returned stable ids for follow-up edits, because aliases shift when tracks are inserted.
update: order, hidden, muted, role, name, or audioRouting via json.
delete: removes only an empty track. It is refused while clips, track effects, layouts, zooms, or adjustment clips remain, so move or delete those items first (edit_item deletes). Delete several empty tracks in ONE call with trackIds; refs resolve before anything is removed, so V2 and V3 together is safe. One timeline per batch.
tighten: close gaps by snapping each item to the end of the previous one.

Roles & ducking

Auto-ducking comes from per-track roles, one role per track, set on the track that actually holds the clips (talking-head speech is often V1's embedded audio, not A1; put music below it). "anchor" = speech track whose items trigger ducking; "follower" = music lowered where it overlaps anchor items; "role":null turns ducking off. Use roles instead of item-level music gain for speech clarity. Leave "audioRouting.duckDepthDb" unset so depth follows timeline loudness; pass a negative dB only when the user wants music louder or softer under speech, and null to clear it. Setting "role":"follower" resets duck depth unless you also pass duckDepthDb.

Effects

Effects on tracks (including Linear Mask) are effect items: add or change them with edit_item type:"effect" and their effect item id. edit_track does not edit effect propertyOverrides.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "edit_track"
  }
}

Input Schema

Name	Required	Description
`json`	No	JSON for create/update, e.g. {"trackType":"video"} or {"trackType":"audio","role":"follower"} or {"role":"anchor"} or {"role":null} or {"audioRouting":{"duckDepthDb":null}}
`action`	Yes	list, create, update, delete, or tighten. delete only works on empty tracks.
`trackId`	No	Track alias (V1, A1) or ID (for update/delete/tighten)
`trackIds`	No	delete: several track aliases/ids removed in one call. Use this instead of repeated single deletes.
`projectId`	No	Project for this call (full ID or unambiguous prefix). Explicit-timeline calls never change the target of later calls; legacy project selection applies otherwise.
`timelineId`	No	Timeline id/prefix (from manage_timelines list) to list/create/update/delete/tighten tracks on without switching the active timeline; defaults to the active timeline. Aliases resolve on it; a concrete track id must belong to it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedNov 5, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Well beyond the annotations, the description discloses alias instability ('aliases shift when tracks are inserted'), ref resolution order in batch deletes, default placement of new tracks, and a non-obvious side effect ('setting role:follower resets duck depth unless you also pass duckDepthDb'). It also scopes exactly what delete will and will not remove, which is the key risk information; the only tension is destructiveHint=false against a delete action, but the description makes clear no content-bearing track can be removed, so this reads as a nuance rather than a contradiction.

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 structure is strong — front-loaded action list, then scannable subsections for Roles & ducking and Effects — and almost every sentence carries operational detail. It is long for a tool description, and the ducking subsection is dense enough that a skimming agent could lose the action list, so it falls just short of a 5 on conciseness.

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 six-parameter, five-action mutation tool with no output schema, the description covers the creation defaults, the failure mode that most often blocks delete, the batching workaround, and the exact sibling to use for track effects. What list returns is described in enough detail (order, stable ids, aliases) that no output schema is needed.

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?

Schema coverage is already 100%, yet the description still adds real meaning: the per-action json payload fields are enumerated, zero-based order is clarified with layer/alias conventions (V1 back layer, A1 top lane), and audioRouting.duckDepthDb is given explicit semantics including the null-to-clear case. The trackIds batch semantics ('refs resolve before anything is removed, so V2 and V3 together is safe') cannot be inferred from the schema at all.

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 opens with an explicit enumeration of the five supported actions (list, create, update, delete, tighten), each with a specific verb and resource semantic, and routes adjacent work to the correct sibling (edit_item for effects and item deletion). An agent can distinguish this from edit_item, split_item, or manage_timelines without opening the 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?

Nearly every action carries a when-to-use instruction: list is framed as 'use it to refresh aliases before another edit,' trackIds is explicitly preferred over 'repeated single deletes,' and roles are preferred over item-level music gain. It also states negative conditions — delete is refused while clips, effects, layouts, zooms, or adjustment clips remain — and names the alternative path (edit_item).

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

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