AskEditor

Transform clip

set_clip_transform

[write] Position, scale, rotate, crop or fit a visual clip; only passed fields change. ids applies one transform to several clips. Use to reframe after a new aspect ratio, make a picture-in-picture or punch in. Not for audio or compound clips, snapping to a frame edge (use align_clip) or movement over time (use set_keyframes). Returns the changed clips' rows (with handles) and counts. Related: align_clip, set_keyframes, set_export_settings.

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": {
      "project_id": "<project_id>"
    },
    "name": "set_clip_transform"
  }
}

Input Schema

Name	Required	Description
`x`	No	Frame-width % from centre (+ right).
`y`	No	Frame-height % from centre (+ down).
`id`	No	get_timeline handle.
`ids`	No	More handles.
`cropB`	No	Inset, 0–1.
`cropL`	No	Inset, 0–1.
`cropR`	No	Inset, 0–1.
`cropT`	No	Inset, 0–1 of the clip.
`items`	No	Many clips at once, max 60, each with this tool's fields.
`scale`	No	Multiplier (1 = fitted size).
`fitMode`	No	fill (default) covers the frame; fit shows it all.
`rotation`	No	Degrees.
`project_id`	Yes	The AskEditor project this acts on (from list_projects).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare write, non-idempotent, non-destructive behavior, and the description reinforces this with '[write]' and adds partial-update semantics ('only passed fields change') plus batch semantics for `ids`. It also states the return shape ('the changed clips' rows (with handles) and counts'), which annotations cannot convey. Minor gap: nothing about permission requirements or what happens with stale handles.

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?

Dense and front-loaded: write marker, action, mutation semantics, use cases, exclusions, return value, related tools, in that order. Slightly over-packed into one paragraph and the trailing 'Related:' list is marginally redundant with the already-named siblings, but no sentence is wasted.

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 13-parameter mutation tool with no output schema, the description covers action, partial-update behavior, batching, exclusions, and return value. An agent has everything needed to invoke it correctly and to avoid the common wrong-tool choices.

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 earns extra by disambiguating the three targeting parameters: `id` for one clip, `ids` to apply a single transform across several, and (via schema) `items` for many clips with individual fields. That distinction is the main source of caller error and the description addresses it directly.

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?

Opens with a bracketed write marker plus specific verbs and resource: 'Position, scale, rotate, crop or fit a visual clip'. It also scopes itself away from audio and compound clips and names the sibling tools (align_clip, set_keyframes) that handle the cases it does not.

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?

Gives both when-to-use ('reframe after a new aspect ratio, make a picture-in-picture or punch in') and explicit when-not along with the correct alternatives ('snapping to a frame edge (use align_clip) or movement over time (use set_keyframes)'). No routing decision is left to inference.

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

All AskEditor 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.

Resources

Need Help?