Slice

Change a clip's frame and layout

set_frame

Use this when the person wants to change how a made clip's picture is framed, anything the Slice editor's Frame tab and Layouts do, with no render. aspect: 9:16, 4:5, 1:1, 16:9, 3:4, source (ask the person which shape first). layout: follow-speaker, follow-both, two-people, face-on-top, face-corner, speaker-slides, fill, whole-blur, whole-black (list_styles kind "layout" says what each is; split screens are 9:16 only). fit (fill or whole) and background (black or blur); crop {scale 1-5, x, y} moves and zooms the picture; frame_on {x, y?, scale?} frames ONE person of a wide shot (x: where their face is across the whole picture, 0 left to 1 right; look at a frame first): a fixed crop that never moves to whoever is talking, so use it, not follow, when the person names who to show. The storyboard (scenes, splits, boxes) uses the clip's frame too. moves [{at_seconds, scale, x, y}] reframe part-way through ([] removes them); split {share, swap, border, corner_size} adjusts a split screen; follow speaker, both or off (Slice finds who is talking, as the editor's Follow the speaker does); logo "brand", false or {path, x, y, width, opacity}; end_frame "brand", false or {path, kind, duration_seconds}. Saves the clip only: the person sees it in Slice and can undo.

Input Schema

Name	Required	Description
`fit`	No
`crop`	No	scale 1 fills the frame, up to 5; x and y -1 to 1 move the picture (0 is centred).
`logo`	No	"brand" (the account's logo), false (none), or { "path" (a file in this account), "x", "y" (0-1, its centre), "width" (0.04-0.6), "opacity" (0-1) }.
`moves`	No	Camera moves: from at_seconds on, the picture is framed like this. Replaces the clip's moves.
`split`	No
`aspect`	No
`follow`	No
`layout`	No
`clip_id`	Yes	The clip's id (from get_episode, get_job or the Slice link).
`frame_on`	No	Frame one person: x (and optionally y) is where their face is in the whole source picture, 0 to 1; scale 1 fills the frame. A fixed crop: speaker follow goes off.
`end_frame`	No	"brand" (the account's end card), false (none on this clip), or { "path", "kind": "image" \| "video", "duration_seconds" }.
`background`	No

Output Schema

Name	Required	Description	Default
`clip_id`	No
`open_in_slice`	No	The clip in the Slice editor, where the person sees the change.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / frame_on

Added value: +{
+  "description": "Frame one person: x (and optionally y) is where their face is in the whole source picture, 0 to 1; scale 1 fills the frame. A fixed crop: speaker follow goes off.",
+  "properties": {
+    "scale": {
+      "maximum": 5,
+      "minimum": 1,
+      "type": "number"
+    },
+    "x": {
+      "maximum": 1,
+      "minimum": 0,
+      "type": "number"
+    },
+    "y": {
+      "maximum": 1,
+      "minimum": 0,
+      "type": "number"
+    }
+  },
+  "required": [
+    "x"
+  ],
+  "type": "object"
+}

AddedOct 30, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare the write profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds real context beyond that: no render, it saves the clip only, effects are visible in Slice and undoable, and it discloses cross-cause effects (frame_on switches follow off; moves replaces existing moves; the storyboard inherits the clip's frame). It does not cover rate limits, auth, 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?

Front-loaded with the when-to-use clause and sized appropriately for a 12-parameter tool, with no filler sentences. It is one dense paragraph of semicolon-separated clauses, though, so an agent parsing specific parameters must scan long parentheticals rather than structured lines.

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 12-parameter mutation tool with nested objects, it covers every top-level parameter, their interactions, and the persistence/undo story; an output schema exists, so return values need no explanation. Nothing essential to invoking it correctly is missing.

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

Parameters3/5

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

With 12 parameters and only 50% schema description coverage, the description does heavy lifting: it explains each layout name's intent, lists valid aspect shapes, defines fit/background, ties split screens to 9:16, explains moves as a replacing list where [] clears it, and clarifies where logo/end_frame accept "brand" vs false vs an object. That is substantially more than the schema alone, though some nested fields (split.share, split.border) remain only implicitly defined.

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 — change how a made clip's picture is framed, i.e. what the Slice editor's Frame tab and Layouts do — and notes 'with no render', which separates it from render-producing siblings like make_clips or restyle_clip. An agent can distinguish it from set_trim and set_caption_style 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 Guidelines5/5

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

Gives explicit routing rules: ask the person which shape first for aspect, use frame_on rather than follow when the person names who to show, look at a frame first, and consult list_styles kind "layout" to learn what each layout is. It names the alternative behaviors and the conditions that select them.

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

All Slice 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?