Skip to main content
Glama

Edit timeline in one go

edit_timeline
Destructive

[write] Several timeline edits in one call, applied in order: each op is a timeline editing tool and its arguments (move_clip, trim_clip, split_clip, add_text, set_clip_transform, set_clip_animation, add_keyframe, add_marker…) or a caption edit (edit_subtitle_line, add_caption_line, position_subtitles, toggle_subtitles, set_subtitle_style). Use it instead of calling those tools one by one. Stops at the first edit that fails and says which. Returns what changed across all of them (changed clips, removed handles, and tracks/transitions/markers when they moved), plus a link to the whole timeline.

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": {
      "project_id": "<project_id>",
      "ops": "<ops>"
    },
    "name": "edit_timeline"
  }
}

Input Schema

NameRequiredDescriptionDefault
opsYesThe edits, in order.
project_idYesThe AskEditor project (from list_projects).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, idempotentHint=false and readOnlyHint=false, but the description adds genuinely new behavior: ops apply in order, execution halts at the first failure and reports which one, implying earlier edits persist. It also discloses the return payload (changed clips, removed handles, moved tracks/transitions/markers, timeline link), which no output schema covers.

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 a [write] marker and the core purpose, then the op vocabulary, then failure and return semantics — no wasted framing. The parenthetical tool list is long but each name earns its place by defining the legal input domain.

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?

For a destructive batch mutation with no output schema, the description covers ordering, failure semantics, and return contents — the things an agent most needs. Minor gaps remain: no mention of the 25-op limit or whether a partial batch can be rolled back.

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 adds value by enumerating the valid `tool` values beyond the schema's vague "e.g. move_clip" and by making the ordered-array semantics of `ops` explicit. It does not explain the 25-op cap or how `args` maps to each tool's parameter set.

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 states a specific verb+resource (batch-applies timeline edits) and immediately enumerates the exact sibling tools whose behavior it composes (move_clip, trim_clip, split_clip, add_text, caption edits). An agent can tell this apart from the individual editing tools without opening 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 Guidelines4/5

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

It gives an explicit routing rule — "Use it instead of calling those tools one by one" — and lists which tools are legal ops, so the alternative is named. It stops short of stating when a single direct call is preferable (e.g. one trivial edit), so it is clear context rather than full when/when-not guidance.

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.

Resources