Skip to main content
Glama

screenstudio_plan_edit

Read-only

Plan an edit from screen recordings: cut dead air, speed up typing, add zooms, and return operations for the editor to apply.

Instructions

Propose an edit from the footage (read the craft resource for taste): keep each beat with lead-in and a readable hold, cut dead air, speed up only typing and waiting, and add few long zooms grouped like Screen Studio's auto-zoom (clicks under 5.3s apart share one zoom that pans). Returns ops ready for screenstudio_editor_apply, its pacing check, scored beats and director's notes (each decision at its playback time with the rule behind it). Styles: balanced (default, product demos), calm (docs and tutorials), snappy (short social clips). keep/drop take source-ms spans to override (keep also protects narrated stretches). Speech from the transcript is never cut or sped up; tightenPausesMs (250-400 for talking videos) trims silences between phrases, removeFillers drops um/uh. speedUps:false for narrated videos. look applies a starting frame (wallpaper, gradient, dark, light, minimal, social; none is a default, choose for the content; keep leaves the project's own frame, even under a recipe); aspect sets the output frame. targetMs fits the edit to a length by dropping the lowest-value beats (never the payoff), listed in droppedBeats; structure hook-demo-payoff also suggests a coldOpen. markers (keep by default when the recording has markers): keep starts a beat at each marker and protects it, retake drops the take before a repeated line, chapters numbers the beats. markerBeatsMs (one length per marker, a narration line's beatMs) keeps [marker, marker + ms] so a hold stretched for a voiced line survives. talkingHead plans camera layouts too (skipped when the recording has no camera). recipe (keynote, social-vertical, changelog, founder-talking-head, tutorial, launch-teaser, docs-walkthrough; see screenstudio_recipes) sets style, look, aspect, plan options, captions, cursor and click sound in one word, and returns its music, voice and export settings; explicit arguments win over the recipe, and the notes say what replaced what. No recipe is applied unless named. brand (a kit saved with screenstudio_brand, or the recipe's brand) lays its own colours, captions, cursor and sound over the plan's config (under a recipe or look, its starting look is left out), and its voice and music replace the recipe's where the recipe has them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dropNo
keepNo
lookNoDefault keep.
zoomNoDefault auto.
brandNo
styleNo
aspectNo
recipeNo
markersNo
maxZoomsNo
speedUpsNoDefault true.
targetMsNo
structureNo
projectPathYes
talkingHeadNo
markerBeatsMsNoVoiced beats: one length per marker, in marker order.
removeFillersNoDefault false.
recipeOverridesNoChange parts of the recipe: style, look, aspect, loupes, plan {...}, rules {...}, config {dotted keys}, music, voice, export. Fields merge into the recipe's.
tightenPausesMsNo
applyStyleConfigNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only cover safety (readOnlyHint=true), and the description adds substantial behavior beyond that: precedence rules ('explicit arguments win over the recipe, and the notes say what replaced what'), protection guarantees ('Speech from the transcript is never cut or sped up'), recipe/brand layering rules, and a concrete statement of what is returned (ops, pacing check, scored beats, director's notes). Nothing here conflicts with readOnlyHint.

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?

Almost every clause maps to a parameter, so the length is largely earned, but it is delivered as one unbroken run-on paragraph with no bullets or grouping, making it hard to scan for a 20-parameter tool. Shorter lists of defaults and precedence rules would materially improve usability.

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 complex, low-schema-coverage tool with no output schema, the description covers the planning workflow, defaults, precedence between recipe/args/brand, and the return shape. A few parameters (maxZooms, applyStyleConfig) and the interaction between zoom='auto' and maxZooms remain uncovered.

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 20 parameters at only 30% schema description coverage, the description carries the burden and mostly succeeds: it defines look, style, recipe, markers, markerBeatsMs, targetMs, structure, keep/drop, speedUps, tightenPausesMs, removeFillers, brand and aspect with semantics and defaults. It leaves maxZooms, applyStyleConfig, projectPath and recipeOverrides (only schema-documented) unaddressed, so the coverage is strong but not complete.

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 specific verb+resource ('Propose an edit from the footage') and immediately distinguishes itself from the write path by noting it returns ops for screenstudio_editor_apply. The sibling it feeds is named, so an agent knows this is the non-mutating planning step, not the apply step.

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 real usage context: 'talkingHead ... skipped when the recording has no camera', 'speedUps:false for narrated videos', 'tightenPausesMs (250-400 for talking videos)', and 'No recipe is applied unless named'. It references screenstudio_recipes and screenstudio_brand for follow-up, though it never states an explicit when-not or names a competing planning tool.

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