Skip to main content
Glama

Add screen takeover

add_screen_takeover

PROJECT-SCOPED: this call acts only on the explicit project_id and returns the project identity with its result. PUSH INTO A SCREEN IN THE SHOT AND LET WHAT IS ON IT BECOME THE WHOLE VIDEO — THE tool for 'zoom into the laptop and continue with the other scene', 'make it go into the phone screen', 'transition into the monitor smoothly', and every request that describes the camera travelling INTO a device and the content taking over. It is ONE continuous move, not a zoom plus a cut: the asset is corner-pinned onto the glass so it plays ON the screen inside the shot, the camera pushes in, the picture flattens out of the screen into the full frame, and the clip cuts in on the SAME frame the push ends on — which is why the join cannot be seen. Do NOT build this out of add_zoom + insert_media: an overlay is drawn ABOVE the zoom, so the content sits flat and still while the shot pushes past it, and the cut lands as a jump. at_output_s is where in the FINAL video the takeover FINISHES and the asset is full screen (the push happens in the duration_s before it). The device shot may be the MAIN footage or a SPLICED-IN video clip: point at_output_s inside an inserted clip that shows the device and the push rides that clip's tail, arriving exactly where it ends (I snap there and say so). duration_s 0.4-5, default 1.2 — 1.0-1.5 is the move people mean. I find the corners THREE ways, in order of trust: first I MATCH the content's own pixels against the filmed glass (the laptop was almost always filmed displaying that very recording — a feature homography gives exact corners INCLUDING rotation and keystone, and the pinned clip then grows out of the very pixels it was filmed playing on, living on the glass from the window's start); else I MEASURE a screen-shaped region from the pixels; else I READ the corners with the vision model. When the corners are matched the content is on the glass the whole window; when they are only measured or read, the glass shows what was FILMED until the push is ~half done and the content dissolves on late (a scene switch visible in a wide shot of the room is the #1 thing users call 'not smooth'), fully there before the picture lands. Momentum carries through the cut either way (a brief settle past full frame); ease='accelerate' dives with speed peaking at the cut. Pass corners only to override all of that (8 numbers x0,y0,x1,y1,x2,y2,x3,y3 as FRACTIONS of the frame in the order top-left, top-right, BOTTOM-LEFT, bottom-right — or a {x,y,w,h} rectangle). clip_start_s picks where in the asset the takeover starts playing; hold_s is how long the asset stays full screen afterwards (default: the rest of it). push 0-1 is how far the camera travels (1 = all the way, the default — there is no further zoom past 1; a push that feels weak is usually a short duration_s, so lengthen the move instead). ease: 'smooth' (default), 'accelerate', 'linear'. settle:false turns OFF the through-cut momentum (the brief zoom past full frame after the handoff that settles back) — use it when the user says the video 'keeps zooming after the transition' or 'zooms then returns', or asks for a dead-flat landing. It REFUSES rather than guessing when it cannot measure the screen, and refuses when the screen is under 8% of the frame (the push would be a >12x blowup). TO CHANGE AN EXISTING TAKEOVER (flat landing, different ease/length), call this again at the SAME arrival: it REPLACES that takeover in one write — parameters you omit are inherited, and its accepted pin corners are reused instead of re-measured (pass corners to force a re-measure). remove_screen_takeover is only for taking the transition OUT.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
easeNo
pushNo
hold_sNo
settleNo
cornersNo
asset_keyYes
duration_sNo
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.
at_output_sYes
clip_start_sNo
motion_motifNoActive Blueprint motion motif id this event executes; never 'hold'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations are all false, so the description carries full burden and delivers extensively: it discloses the refusal conditions (cannot measure screen, screen under 8% of frame), the replacement semantics (REPLACES existing takeover, inherits omitted params, reuses pin corners), the momentum/settle behavior, and the three-way corner detection order. The description's write semantics ('replaces... in one write') are consistent with readOnlyHint=false — no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a ~700-word wall of text that is front-loaded well but poorly structured: ALL-CAPS emphasis, long parenthetical asides, and repeated explanations (corner matching is covered in a ~150-word digression with redundant phrases like 'living on the glass from the window's start' and 'fully there before the picture lands'). The same operational facts could be delivered in roughly half the length; the verbosity taxes the agent's context window despite the valuable content.

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?

Given the complexity (11 params, 18% schema coverage, no output schema, all-false annotations), the description is exhaustive: every parameter is explained, refusal and replacement behavior is stated, corner-detection strategy is documented, and the distinction from remove_screen_takeover is drawn. Nothing an agent needs to call this correctly is missing.

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?

Schema coverage is only 18%, so the description must compensate and does so thoroughly: it defines at_output_s (where the takeover FINISHES), duration_s (0.4-5, default 1.2, recommended 1.0-1.5), corners (8 fractions in top-left, top-right, BOTTOM-LEFT, bottom-right order or a rect), clip_start_s, hold_s (default rest of asset), push (0-1, 1=all the way), ease (three values), and settle. This far exceeds what the sparse schema provides.

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 description names a specific verb+resource ('camera travels INTO a device and the content takes over') and gives concrete user-phrase examples ('zoom into the laptop and continue with the other scene'). It explicitly differentiates from siblings add_zoom and insert_media, explaining that an overlay drawn ABOVE the zoom makes the content sit flat while the shot pushes past. An agent can unambiguously select this tool for device-screen takeover transitions.

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?

Provides explicit when-to-use ('every request that describes the camera travelling INTO a device'), an explicit when-NOT-to-use ('Do NOT build this out of add_zoom + insert_media' with the failure reason), and the alternative for removal ('remove_screen_takeover is only for taking the transition OUT'). It also documents the idempotent-replacement pattern (call again at the same arrival to change an existing takeover). Nothing about selection 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.