Skip to main content
Glama

Reframe for a vertical or square platform

auto_reframe

PROJECT-SCOPED: this call acts only on the explicit project_id and returns the project identity with its result. THE tool for 'make it 9:16 / vertical / for TikTok'. It samples frames across the kept footage and MEASURES two things before writing the frame: where the subject is (faces found in the pixels; vision or a detail-energy estimate only when there is no face), and whether a crop is the right operation at all — how much of the picture's detail would survive the crop window. With mode='auto' (default) footage with a subject gets a crop aimed at it, and footage whose content runs to the edges (gameplay, screen recordings, wide scenes) is FITTED into the new frame over a blurred backdrop so nothing is cut off — cropping those is the 'it just truncated my video instead of adjusting it' complaint. Low-resolution footage a crop would enlarge past ~2.5x (480p/archival 4:3) is FITTED as a window instead, with the free headline band reported. A crop slides off a burned-in inset or border that would leave a thin sliver at its edge (an EDGE BAND note asks you to look when it cannot). FOLLOW (default on): inside each shot the crop follows the speaker's face, measured on the kept footage (4 fps) — it holds STILL while they sway and glides (eased, speed-limited, never a whip, never across a cut) only when they move far enough that a still crop would cut the head or lose the composition; a re-aim that can land on a jump cut happens on the cut. A speaker who stays put gets no motion; a shot with two or more people keeps its aim. follow=false keeps one aim per shot. A tight close-up whose speaker TURNS keeps the leading edge of the face (the nose side) clear of the frame edge — the re-aim happens when the face nears the edge, never on every sway; a turned head the detector loses is tracked through the turn. SCREEN INSETS: a burned-in screen or picture-in-picture box the crop would cut through is slid out of the crop when the speaker stays framed (SCREEN INSET CLEARED), else named with the calls that show it legibly (a speaker + screen stack per camera shot, or for a beat set_picture_card source='inset'). A crop that shows NO FACE for over a second while someone speaks is named with the fix. Pass mode explicitly to force one. Read what it reports and repeat THAT.

Input Schema

NameRequiredDescriptionDefault
modeNo
ratioYes
followNo
project_idYesRequired immutable scope for this call. Copy the id from list_projects/open_project/project_state; the active-project pointer is never used to guess.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / follow
      Added value: +{
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare a non-readonly, non-destructive, non-idempotent mutation; the description adds deep context the annotations cannot — frame sampling, face/detail-energy measurement, the ~2.5x enlargement threshold for fitting low-res footage, follow easing/speed limits, edge-band and screen-inset handling, and the 'no face while speaking' named fix. It also correctly frames itself as project-scoped with an immutable project_id.

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?

The critical scoping and default information is front-loaded, but the body is a dense all-caps wall of edge-case prose that reads as accumulated caveats rather than prioritized guidance. Several clauses (screen inset, turned-head tracking) could be compressed without losing actionable meaning.

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 mutation tool with no output schema, the description does the necessary work of stating what it returns ('the project identity with its result') and what diagnostic notes come back (EDGE BAND, SCREEN INSET CLEARED). It is complete enough to call and interpret, though the sheer density could obscure the primary path.

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 only 25% schema coverage, the description compensates well for mode ('auto' default, and forcing crop/fit) and follow (default on, false keeps one aim per shot), which are the two behaviorally complex params. It adds little for ratio's enum values and gives no guidance on 'source', leaving a gap, but overall it carries most of the semantic burden.

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+resource and immediately positions itself as 'THE tool for make it 9:16 / vertical / for TikTok', which lets an agent distinguish it from siblings like add_aspect_shift, deliver_aspects, or apply_format_pack without opening a schema. The framing is unambiguous about what it produces.

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?

Gives clear operating context: mode='auto' is the default and picks crop vs fit per footage, follow defaults on, and 'Pass mode explicitly to force one' tells the agent when to override. It does not, however, name a competing sibling tool or state when-not to use this one, so it stops short of explicit alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.