Reel-E

Frame a shot

frame_shot

Destructive

Chooses which part of a shot's photo each version shows: Wide (16:9), Square (1:1) or Phone (9:16). Uses no credit; undoable. A version's framing is its own: framing Phone leaves Wide and Square alone. There are four ways to frame, one per call: (a) focusX, focusY (0 to 1, where in the photo the frame centers; 0.5 is the middle) and zoom (1 to 3); (b) a nudge: zoomBy (zoom in is +0.25 for a bit), moveX / moveY (-0.1 moves the frame a little left or up, +0.1 right or down; the frame moves, so the picture appears to slide the other way); (c) frames: one {photoId, focusX, focusY, zoom} per shot, for when each shot needs its own frame (find_framing returns ready frames); or (d) reset true to go back to the default framing. aspect 'all' frames every version at once; a reset with 'all' clears the framing completely.

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": {
      "listingId": "<listingId>",
      "aspect": "<aspect>"
    },
    "name": "frame_shot"
  }
}

Input Schema

Name	Required	Description
`zoom`	No	How far in the frame is, 1 (whole photo) to 3.
`moveX`	No	A nudge sideways, -1 to 1; -0.1 moves the frame a little left.
`moveY`	No	A nudge up or down, -1 to 1; -0.1 moves the frame a little up.
`reset`	No	true goes back to the default framing.
`aspect`	Yes	Which version: wide, square, phone, or all.
`focusX`	No	Where the frame centers across the photo, 0 (left) to 1 (right); 0.5 is the middle.
`focusY`	No	Where the frame centers down the photo, 0 (top) to 1 (bottom); 0.5 is the middle.
`frames`	No	One frame per shot, for shots that each need their own (find_framing returns them).
`zoomBy`	No	A nudge to the current zoom, -2 to 2; +0.25 is a bit closer.
`allShots`	No	Frame every shot in the video.
`photoIds`	No	The shots to frame. Not needed with allShots or frames.
`listingId`	Yes	Listing id from list_listings.

Output Schema

Name	Required	Description	Default
`status`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedNov 10, 2026

addedInput schema / properties / focusX / description

Added value: +"Where the frame centers across the photo, 0 (left) to 1 (right); 0.5 is the middle."

addedInput schema / properties / focusY / description

Added value: +"Where the frame centers down the photo, 0 (top) to 1 (bottom); 0.5 is the middle."

addedInput schema / properties / frames / description

Added value: +"One frame per shot, for shots that each need their own (find_framing returns them)."

addedInput schema / properties / frames / items / properties / focusX / description
```
Added value: +"Where this shot's frame centers across the photo, 0 to 1."
```
addedInput schema / properties / frames / items / properties / focusY / description
```
Added value: +"Where this shot's frame centers down the photo, 0 to 1."
```
addedInput schema / properties / frames / items / properties / zoom / description
```
Added value: +"How far in this shot's frame is, 1 to 3."
```

addedInput schema / properties / moveX / description

Added value: +"A nudge sideways, -1 to 1; -0.1 moves the frame a little left."

addedInput schema / properties / moveY / description

Added value: +"A nudge up or down, -1 to 1; -0.1 moves the frame a little up."

addedInput schema / properties / reset / description

Added value: +"true goes back to the default framing."

addedInput schema / properties / zoom / description

Added value: +"How far in the frame is, 1 (whole photo) to 3."

addedInput schema / properties / zoomBy / description

Added value: +"A nudge to the current zoom, -2 to 2; +0.25 is a bit closer."

First observedNov 9, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the annotations it discloses real behavioral facts: the operation costs no credit, it is undoable, and framing one version leaves the other versions untouched. It also explains the destructive edge case — a reset with aspect 'all' clears framing completely. The only friction is the mild tension between 'undoable' and destructiveHint=true, which is not reconciled (undoable via reset vs. overwriting existing framing).

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?

It is a single dense paragraph, front-loaded with the what/why before the mode list, and the lettered (a)-(d) structure makes scanning easy. A few parentheticals are wordy ('where in the photo the frame centers; 0.5 is the middle' partially repeats the schema), but nothing is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter mutation tool the description covers the framing modes well and an output schema exists, so return values need no explanation. However, it never mentions allShots or photoIds, leaving ambiguous how shot targeting relates to aspect 'all', and it is silent on what happens with conflicting or out-of-range mode combinations.

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?

With 100% schema coverage the baseline is 3, and the description earns above that by adding semantics the schema does not: the counterintuitive directionality of moveX/moveY ('the frame moves, so the picture appears to slide the other way') and the practical scale of nudges (+0.25 zoomBy is 'a bit'). It does not, however, explain photoIds or allShots, so two parameters are left entirely to the schema.

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 — choosing which part of a shot's photo each version (Wide/Square/Phone) shows — which is unmistakably distinct from sibling operations like move_shot or set_shot_length. It also references find_framing as the source of ready-made frames, giving the agent a second anchor for what this tool is not.

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

Usage Guidelines4/5

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

The description enumerates four concrete invocation modes (focusX/focusY/zoom, nudge via zoomBy/moveX/moveY, per-shot frames, and reset) and points to find_framing when frames are needed, which is strong how-to-call guidance. What it lacks is explicit exclusion logic — e.g. whether modes can be combined in one call or which wins if focusX and zoomBy are both supplied.

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

All Reel-E 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?