Skip to main content
Glama
Sign In

CutClip.one

by one.cutclip
OverviewDiscussionsAdmin

timeline.add_transition

Add a transition (§4.1: crossfade, smooth_blend, fade_from_black, or fade_to_black — a hard cut needs no call at all, it's just the default). crossfade and smooth_blend require fromItemId and toItemId to be two contiguous, back-to-back clips on the same track, and shift toItemId durationMs earlier so the overlap uses only content the clips already have (no source 'handle' footage needed) — this shortens the sequence by durationMs, exactly like a real NLE. smooth_blend is the least noticeable join: the same overlap as crossfade, but eased (cosine) at both ends so the blend has no perceptible start or end; prefer it when the goal is for the viewer not to notice the transition. fade_from_black/fade_to_black only need fromItemId (the clip being faded) and apply within its own bounds.

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": {
      "projectId": "<projectId>",
      "expectedVersion": "<expectedVersion>",
      "trackId": "<trackId>",
      "kind": "<kind>",
      "durationMs": "<durationMs>",
      "fromItemId": "<fromItemId>"
    },
    "name": "timeline.add_transition"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYes
trackIdYes
toItemIdNo
projectIdYes
durationMsYes
fromItemIdYes
expectedVersionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it discloses the side effect of shifting toItemId durationMs earlier, that the sequence gets shorter, that no handle footage is required, the contiguity precondition, and that fades are applied within the clip's own bounds. It omits any mention of version-conflict behavior or failure modes, which matters for a mutation.

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 most decision-relevant facts (valid kinds, hard-cut default) are front-loaded, and the parentheticals each carry real signal rather than filler. The em-dash-heavy sentence structure is dense but not padded.

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 7-parameter mutation with no annotations and no output schema, the description supplies the domain model an agent needs — overlap mechanics, contiguity requirement, per-kind minimum inputs. The gaps are expectedVersion/concurrency semantics and any hint of what the call returns.

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 0%, so the description must compensate across 7 parameters. It explains kind (all four values), fromItemId/toItemId with per-kind requirements, and durationMs' effect on sequence length, but projectId, trackId (only implied via 'same track'), and especially expectedVersion — an optimistic-locking token — are never explained.

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 a specific verb+resource ('Add a transition') and immediately scopes the operation by enumerating the four valid kinds and their §4.1 semantics. It also clarifies the negative case — a hard cut needs no call — so an agent can tell this tool apart from an edit operation without inspecting 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 Guidelines4/5

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

It gives concrete when-to-use guidance ('prefer smooth_blend when the goal is for the viewer not to notice'), per-kind applicability rules, and a when-not-to-use case (hard cut). It stops short of naming siblings such as timeline.add_transitions or timeline.update_transition_duration, so the agent gets context but not explicit routing.

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

All CutClip.one toolsInspect
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.

Resources