Skip to main content
Glama
Sign In
filmcraft-edit

filmcraft-edit

by kanishk-gangwar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_effect_param

Set a single clip effect parameter to a fixed value or keyframe it at a timeline time to animate motion, opacity, or Lumetri settings.

Instructions

Set one effect parameter on a clip: a fixed value, or a keyframe at a timeline time (keyframe=true animates it). Motion: scale, position [x,y], rotation. Opacity: opacity, blend ("Screen", "Multiply"…). Lumetri: exposure, contrast, temperature, saturation, curve_red/green/blue [[x,y]…], vignette_amount…

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": {
      "clip": "<clip>",
      "effect": "<effect>",
      "param": "<param>",
      "value": "<value>"
    },
    "name": "set_effect_param"
  }
}

Input Schema

NameRequiredDescriptionDefault
clipYesTimeline clip id (from list_timeline)
timeNoTimeline seconds for the keyframe
paramYes
valueYesNumber, [x, y], #rrggbb, bool, option name, or curve points
effectYesEffect id ("lumetri", "gaussian_blur", "motion", "opacity"…) or its index in the clip's effect list
projectNoPath to the .fcproj project file; omit to edit the FilmCraft app connected with connect_app
keyframeNoWrite a keyframe at `time` (and animate the parameter)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations only declare readOnlyHint=false and openWorldHint=false, so the description carries most of the burden. It usefully discloses that keyframe=true causes an animated side effect persisting over the timeline, but it does not say whether writing a keyframe overwrites existing keyframes at that time, whether the parameter must already be keyframable, or what happens on an invalid param name — significant gaps for a mutation tool.

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 front-loaded sentence states the action and the two modes before the parameter catalogue, so the agent gets the core semantics first. The grouped-by-family listing (Motion / Opacity / Lumetri) is scannable, though the trailing ellipses leave the enumeration open-ended rather than definitive.

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 tool with no output schema, the description covers the action, the two write modes, and the parameter/value vocabulary, which is the bulk of what an agent needs. The remaining gap is error and prerequisite behavior — whether the effect must exist first and what a rejected param returns — which is not addressed anywhere else in the structured data.

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 86%, so the baseline is 3, but the description earns above baseline by supplying the actual param vocabulary the schema omits: 'param' is a bare string in the schema, yet the description enumerates scale, position [x,y], rotation, opacity, blend option names, exposure/contrast/temperature/saturation, curve_red/green/blue as [[x,y]…], and vignette_amount. This directly explains the enum-free but effectively-enumerated value shapes.

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?

States a specific verb and resource — 'Set one effect parameter on a clip' — and immediately qualifies the two modes (fixed value vs. keyframe). The distinction from the sibling apply_effect is only implicit; the description never says an effect must already exist, so an agent must infer the boundary between adding an effect and setting a parameter on one.

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?

The parenthetical 'keyframe=true animates it' gives real guidance on choosing between the two write modes, which is the main branch point for this tool. However there is no when-not guidance, no prerequisite telling the agent it must first apply_effect or verify the effect exists, and no mention of how this relates to fade or apply_effect.

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

Deploy Server

Other Tools