Skip to main content
Glama

split_item

Cut one or more timeline items at given frame positions. One call can split many items, each at one or many frames.

When to use

Cut a clip into pieces while preserving its source mapping, fades, effects, transitions, and markers. Splitting does not change which spoken content plays — the same media bytes play end-to-end across the resulting pieces.

Use this for physical clip management: preparing a transition, isolating a piece for visual treatment, splitting around an effect boundary, or making manual timeline organization easier while the content still plays the same.

For trimming (shortening one edge), prefer edit_item updates on durationInFrames + the source-offset field. Use split_item when you actually need two or more pieces.

When NOT to use

Do not use split_item for transcript-based editing: clipping/highlight extraction, "cut slices", "keep the part about X", deleting a sentence, removing a retake, or making a short version based on what the speaker says. Do not take frames from find_transcript, split at those frames, and delete pieces to select spoken content. Use Script instead: read_script → edit timeline.md → apply_script.

Body shape

{"splits": [{"id": "...", "atFrame": 90}, {"id": "...", "atFrames": [60, 120, 180]}]}

Each entry:

  • id: timeline item id (short prefix from preview_timeline accepted).

  • atFrame: single timeline-frame cut position.

  • atFrames: multiple cut positions; the item is cut into N+1 pieces.

Both atFrame and atFrames accept timeline frames (not source seconds). All cut frames must lie strictly inside the item (from < cut < from + durationInFrames).

What survives the cut

  • Source offset — each piece keeps the correct sourceStartFromInSeconds slice of the source media, accounting for playbackRate.

  • Fades — fadeIn / audioFadeIn stays on the first piece only; fadeOut / audioFadeOut stays on the last piece only. Middle pieces have all fades zeroed.

  • Effects — clip-anchored effects follow the resulting piece and split at cut points when necessary.

  • Transitions — a transition where the original item was the outgoing side now points at the last piece; incoming-side transitions point at the first piece.

  • Adjustment-track effects keep their absolute timeline range unchanged.

  • Markers — clip markers move to whichever piece contains them; item-local markers have their fromFrame re-anchored.

Constraints

  • Cannot split effect or transition items. Use edit_item to delete those.

  • Canonical caption Programs are timeline-wide subtitle containers and cannot be split into clips. Regular caption clips still support frame cuts. To split a caption Card at word boundaries, call read_captions {"words":true} for its Card id, current revision, and timed word token ids, then edit_captions with top-level action="split_card" and json containing cardId, revision, and beforeWordKey (or beforeWordKeys). This does not turn arbitrary frame cuts into word boundaries or hide a time range.

  • A single split_item call may not list the same id twice. Combine cuts for one item into a single atFrames array.

  • Locked tracks reject splits with a clear error.

Return

{"splits": [{"itemId": "<original prefix>", "type": "video", "newIds": ["<piece1>", "<piece2>", ...]}, ...]}

The original item id is deleted after the call. Subsequent edits should reference the returned newIds.

Examples

  • Single cut on one item: {"splits": [{"id": "abc123", "atFrame": 150}]}

  • Three cuts on one item (4 pieces): {"splits": [{"id": "abc123", "atFrames": [60, 120, 180]}]}

  • Cut two different items in one call: {"splits": [{"id": "abc123", "atFrame": 60}, {"id": "def456", "atFrames": [30, 90]}]}

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": {
      "json": "<json>"
    },
    "name": "split_item"
  }
}

Input Schema

NameRequiredDescriptionDefault
jsonYes{"splits":[{"id":"...","atFrame":150}]} or {"splits":[{"id":"...","atFrames":[60,120]}]}
projectIdNoProject for this call (full ID or unambiguous prefix). Explicit-timeline calls never change the target of later calls; legacy project selection applies otherwise.
timelineIdNoTimeline id/prefix (from manage_timelines list) holding every listed item. Edits that timeline without switching the active timeline; defaults to the active timeline.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it documents what happens to source offsets, fades, effects, transitions, adjustment-track effects and markers across the cut, states that the original item id is deleted and `newIds` must be used afterwards, and lists failure modes (effect/transition items, caption Programs, duplicate ids per call, locked tracks). The id-replacement behavior is the important nuance `destructiveHint=false` does not convey, and the description supplies it.

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?

Markdown headers make it scannable and the core action is front-loaded before the caveats. It is long, and the '# Body shape' block plus the '# Examples' block partly duplicate the body example already embedded in the `json` schema description, which is some redundancy for a tool an agent will call repeatedly.

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?

No output schema exists, and the description compensates by spelling out the return shape and the id-lifecycle consequence. Combined with the constraint list and the surviving-attribute breakdown, an agent has everything needed to call it correctly and chain the follow-up edits.

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 coverage is 100%, so the baseline is 3, but the description materially enriches the opaque `json` string parameter: it gives the full body shape, explains `atFrame` vs `atFrames` (N+1 pieces), notes that short id prefixes from `preview_timeline` are accepted, and constrains cuts to lie strictly inside the item. It does not address the `projectId`/`timelineId` scoping semantics (e.g. that one timeline must hold every listed item) beyond what the schema already says, which keeps it just short of a 5.

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?

Opens with a concrete verb+resource plus scope: 'Cut one or more timeline items at given frame positions,' and immediately clarifies the batch semantics. It is explicitly differentiated from `edit_item` (trimming) and `apply_script` (transcript-based editing), so an agent can pick it out of a large sibling list 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?

Has dedicated '# When to use' and '# When NOT to use' sections naming the alternatives and the exact conditions that select them (`edit_item` with `durationInFrames` + source offset for trims, `apply_script` for any spoken-content editing, `edit_captions` with `split_card` for caption word boundaries). It even warns against the common wrong pattern of taking frames from `find_transcript` and deleting pieces.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.