Valmera — agentic AI video editor

Add zoom

add_zoom

PROJECT-SCOPED: this call acts only on the explicit project_id and returns the project identity with its result. Camera move (sub-pixel, eased) on a time range of the FINAL edited video, in output seconds. OPTIONAL, never a rule: a steady, well-framed picture is the default, and a zoom needs a clear editorial reason (the word the story turns on, a real cut between ideas, a thing the viewer must look at) — zooms where nothing calls for them make an edit look childish, so never one on every cut, sentence or hold. When a move is earned, each one has a job and lands on a real beat: 'punch' = fast expo snap in (~0.15s), held, hard cut back out at end — THE punch-in on a stressed word, number or payoff; end it on the next cut or sentence turn so the step back reads as a second camera, and add overshoot 0.05-0.15 for a slam that settles on the biggest beats. 'landing' = starts pushed in (strength 0.12-0.18) and settles to the wide in ~0.35s — start it EXACTLY on a cut (end ~start+0.4) so the new shot arrives with momentum. 'push_in' = slow continuous push (strength 0.05-0.12) across a long hold (3s+) that builds toward something; 'pull_out' = the release/reveal. 'ease' (default) = smooth ramp in, hold, ramp out — a gentle push onto a subject mid-shot. An edge within 4 frames of a cut lands ON the cut and holds through it: no ramp straddles a cut, and a punch/ease starting on a cut is in on its first frame (it ramps from the wide instead when the frame before the cut is already pushed in about as far). 'pulse' = 1 -> 1+strength -> 1 in ~0.3s on a beat or hit word (strength 0.05-0.08). 'shake' = a decaying impact shake (strength unused; shake 0.3-0.8). Vary mode, strength and spacing — never the same punch on a metronome. Knobs: ramp_s = how long the move takes (punch ramp_s=0 is a hard one-frame step; a landing or pulse needs >= 0.06), overshoot 0-0.5 (punch/ease), rotate = degrees of roll riding the move (+ clockwise, 1-3 for a dynamic punch), shake 0-1 with shake_hz/shake_decay on ANY mode (punch + shake 0.4 = an impact hit). strength 0.05-4.5 (default 0.15; pulse 0.07; above 1.0 is a dramatic 2x+), capped so the footage is never enlarged past 3x in total (framing x zoom — the result says when). TWO ways to aim, and they answer different requests: rect=[x0,y0,x1,y1] (fractions of the output frame, read off look_at's grid) FRAMES A REGION — the tool solves strength and centre so that box fills the frame with margin, THE way to 'zoom into the message / that button / this panel', and its result reports where the region lands on screen. cx/cy instead PIN A POINT: that point keeps its exact screen position while everything magnifies around it — right for a punch on a face that is already well-composed, and wrong for framing a thing near an edge (an edge point stays at the edge at any strength — it never slides to centre). Pass rect OR cx/cy, not both; if both arrive the rect wins (it already determines the centre) and the call still succeeds. Omitting all targets uses the frame center and returns a quality advisory. Coordinates may come from look_at, the filmstrip, user direction, or the editor's own judgment; no prior evidence call is required. punch_in_on_emphasis places punches on the measured vocal stress peaks in one call. If the zoom should MOVE while pushed in — 'then move it to X', 'keep it and go to the next message', 'follow the cursor' — that is ONE add_zoom_path (its keyframes take rect too), never a chain of static zooms.

Input Schema

Name	Required	Description
`cx`	No
`cy`	No
`end`	Yes
`mode`	No
`rect`	No
`shake`	No
`start`	Yes
`ramp_s`	No
`rotate`	No
`purpose`	No	The nameable narrative or visible reason for this zoom.
`shake_hz`	No
`strength`	No
`overshoot`	No
`project_id`	Yes	Required immutable scope for this call. Copy the id from list_projects/open_project/project_state; the active-project pointer is never used to guess.
`shake_decay`	No
`motion_motif`	No	Active Blueprint motion motif id this event executes; never 'hold'.
`target_evidence_ids`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 9, 2026

changedInput schema / properties / mode / enum

Previous value: -[
-  "punch",
-  "ease",
-  "push_in",
-  "pull_out"
-]New value: +[
+  "punch",
+  "ease",
+  "push_in",
+  "pull_out",
+  "landing",
+  "pulse",
+  "shake"
+]

addedInput schema / properties / overshoot
```
Added value: +{
+  "type": "number"
+}
```
addedInput schema / properties / ramp_s
```
Added value: +{
+  "type": "number"
+}
```
addedInput schema / properties / rotate
```
Added value: +{
+  "type": "number"
+}
```
addedInput schema / properties / shake
```
Added value: +{
+  "type": "number"
+}
```
addedInput schema / properties / shake_decay
```
Added value: +{
+  "type": "number"
+}
```
addedInput schema / properties / shake_hz
```
Added value: +{
+  "type": "number"
+}
```

First observedSep 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare non-readonly/non-destructive/non-idempotent. The description adds substantial context beyond that: the hard 3x total-enlargement cap, conflict resolution ('if both arrive the rect wins and the call still succeeds'), the frame-center fallback with a quality advisory, and what the result reports. It also confirms behavior on edge cases without contradicting the 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?

Front-loaded correctly with scope then core behaviour, and most sentences carry real information, but the block is far larger than a typical tool description and reads partly as an editorial style guide (metronome punches, childish edits, overshoot for a 'slam'). It is dense and hard to scan; a leaner version would serve tool selection better.

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 17-parameter mutation tool with no output schema, it is very complete on invocation: aiming modalities, mode semantics, caps and failure/fallback behaviour are all covered. It only gestures at the response ('the result says when', 'its result reports where the region lands') without describing the return shape, leaving a small gap.

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

Parameters5/5

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

With only 18% schema coverage across 17 params, the description compensates heavily: it defines every mode value (punch, landing, push_in, pull_out, ease, pulse, shake) with duration and strength guidance, gives strength ranges/defaults, ramp_s semantics, overshoot/rotate/shake ranges, and the mutually exclusive rect vs cx/cy aiming model and their distinct behaviours. Only purpose, motion_motif and target_evidence_ids are left to the schema, and two of those carry schema descriptions.

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?

States a specific verb and resource ('Camera move ... on a time range of the FINAL edited video, in output seconds') and immediately scopes it ('PROJECT-SCOPED: this call acts only on the explicit project_id'). It also distinguishes itself from siblings add_zoom_path, punch_in_on_emphasis, remove_zoom and remove_zoom_path with explicit routing rules.

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

Usage Guidelines5/5

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

It gives explicit when-to-use and when-NOT-to-use guidance ('OPTIONAL, never a rule ... never one on every cut, sentence or hold'), details the editorial conditions that earn a zoom, and names the alternatives ('that is ONE add_zoom_path, never a chain of static zooms'; 'punch_in_on_emphasis places punches on the measured vocal stress peaks in one call').

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

All Valmera — agentic AI video editor tools Inspect

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.

Add zoom

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources