Skip to main content
Glama

Put an effect over a clip

apply_effect

Put one effect from search_effects into the film. It writes the effect on a new track in front of the clip it goes over, adds what the effect draws to the project, and makes what the effect needs. An effect on a person reuses a person mask of the clip's footage, or runs cutout_subject on the part of the footage the effect covers. An effect on a face reuses a face track of that footage, or runs track_faces there and takes the first face. Those runs use credits as those tools do. at is the timeline second the effect starts. duration null uses the effect's own length. clipId is the video clip the effect goes over: an effect on a person or a face needs it, and every effect sits in front of it when it is given. values is JSON text of the settings that differ from the effect's defaults, such as {"emoji": "😭"} or {"face": "track_face_2"}; photos go in by Asset ID, such as {"top": "img_a", "bottom": "img_b"}. region is the part of the frame an overlay effect covers, as [x0, y0, x1, y1] fractions of the frame; null uses the effect's own box, most often the whole frame. Use one effect per moment, on a real beat or impact: an effect on every cut reads as noise. It writes the current version. The effect is in the film at once, and the editor shows it waiting while its mask or face is made; if that cannot be made, the effect is taken out again and the answer says why. A long cutout answers with a Job ID: wait for it with wait_for_jobs, and the effect plays when the cutout ends. Check the result with preview_frame.

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": {
      "effectId": "<effectId>",
      "at": "<at>",
      "duration": "<duration>",
      "clipId": "<clipId>",
      "values": "<values>",
      "region": "<region>",
      "projectId": "<projectId>"
    },
    "name": "apply_effect"
  }
}

Input Schema

NameRequiredDescriptionDefault
atYesTimeline second the effect starts.
clipIdYesId of the video clip the effect goes over, from read_film. Needed for an effect on a person or a face. null places the effect in front of every track.
regionYesThe part of the frame an overlay effect covers, as [x0, y0, x1, y1]: its top left and bottom right corners as fractions of the frame. null (or leaving it out) uses the effect's own box, most often the whole frame. An effect drawn on a person or a face ignores it.
valuesYesJSON text of the effect's settings that differ from its defaults, as search_effects lists them, such as {"emoji": "😭"}. Photos go in by Asset ID. null keeps every default.
durationYesHow long the effect runs on the timeline, in seconds. null uses the effect's own length.
effectIdYesEffect id from search_effects.
projectIdYesThe project this call runs on without changing the open project. null (or leaving it out) uses the open project. wait_for_jobs takes the projectId of the calls that started the jobs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only cover the safety flags (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description carries real weight here and delivers: it writes on a new track, adds assets, creates masks/face tracks, consumes credits, writes the current version, rolls the effect back on failure, and returns a Job ID for long cutouts. This is exactly the async/rollback/credit context an agent needs and cannot get from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a dense run-on block that folds parameter explanations into mid-paragraph prose ('at is the timeline second the effect starts. duration null uses...') rather than organizing them. The length is defensible for a complex tool, but the structure makes it harder to scan than it needs to be.

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 complex, non-idempotent mutation with no output schema, the description covers what an agent must know: async Job ID handling via wait_for_jobs, rollback on mask/face failure, credit consumption, and verification via preview_frame. Nothing critical is left for the agent to discover by trial.

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 goes further: it explains values with concrete JSON examples ({"emoji": "😭"}, {"face": "track_face_2"}, Asset-ID photos), clarifies that region is [x0,y0,x1,y1] fractions and is ignored for person/face effects, and states when clipId is required. These examples add meaning beyond the schema text.

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 first sentence names a specific verb and resource ('Put one effect from search_effects into the film') and immediately describes the concrete side effects (new track, added assets, mask/face creation). It distinguishes itself from siblings by naming search_effects, cutout_subject, track_faces, wait_for_jobs, and preview_frame in their proper roles. An agent can tell what this tool does 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 Guidelines3/5

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

It gives stylistic usage advice ('Use one effect per moment, on a real beat or impact: an effect on every cut reads as noise') and routes effectId lookup to search_effects, but never contrasts itself with the sibling prepare_effect or states explicit when-not-to-use conditions. Usage is implied rather than specified as a selection rule.

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.