Skip to main content
Glama

trim_clip

Adjust the source in and out points of a clip already on the timeline to change which portion of its media is used, using project name, producer ID, and new in/out seconds.

Instructions

Change the source in/out points of a clip already on the timeline.

Input Schema

NameRequiredDescriptionDefault
in_sNo
out_sNo
producer_idYes
project_nameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden and does not meet it: it doesn't say whether the trim is destructive to existing clip data, what happens if in_s exceeds out_s, or whether producer_id is a clip identifier or a media source. 'Already on the timeline' hints at a precondition but nothing about reversibility or failure modes.

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?

A single clear sentence with the key qualifier ('already on the timeline') front-loaded and no filler. It earns its place, though it is thin enough that a second clause on scope would not have hurt.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, one sentence is well short of what an agent needs to invoke it safely. Missing: which parameter identifies the clip, what the call returns, and what happens on invalid ranges.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate and only does so for in_s/out_s via 'source in/out points'. The two required parameters, project_name and producer_id, get no explanation at all — notably whether producer_id refers to the clip being trimmed. Units for in_s/out_s are implied as seconds only by the name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('Change the source in/out points') applied to a specific resource ('a clip already on the timeline'), which separates it from move_clip and split_clip. It stops short of naming those siblings explicitly, so the differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No statement of when to use this versus move_clip, split_clip, or remove_segment, and no preconditions such as the clip needing to already exist. The agent must infer usage from the one-line purpose.

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