Osiris Premiere MCP

Overview Schema Source Related Servers Discussions Admin

Plan Multicam Angle Switches

plan_multicam_angle_switches

Read-onlyIdempotent

Plan active-speaker camera cuts from speaker segments and camera maps. Produces angle cut lists with minimum holds, cover shots, razor times, and markers for multicam editing.

Instructions

Plan active-speaker camera switching for stacked, synced camera tracks: from speaker segments and a camera-to-speaker map it produces an angle cut list with minimum holds, crosstalk cover shots, optional lead-in cuts and periodic cutaways, plus razor times, per-camera enable/disable ranges, and markers. Local-only and deterministic; never changes Premiere.

Input Schema

TableJSON Schema

Name	Required	Description
`cameras`	Yes	Camera angles. A camera with one speaker is a single, two or more is a two_shot, none is a wide cover unless role says otherwise.
`frame_rate`	No	Sequence frame rate for snapping cut points; defaults to 30.
`marker_color`	No	Marker color index for the cut markers (default 6 = blue).
`start_seconds`	No	Plan start in sequence seconds (default 0).
`cutaway_seconds`	No	Length of each cutaway (default 2.5; must be at least min_hold_seconds).
`cover_on_overlap`	No	Cut to a two_shot or wide camera when speakers overlap (default true).
`min_hold_seconds`	No	Minimum time an angle stays on air; shorter changes are absorbed (default 2).
`speaker_segments`	Yes	Who is speaking when, in sequence seconds (from a transcript, diarization, or plan_speaker_checkerboard turns). Overlaps are allowed.
`lead_switch_seconds`	No	Cut to the incoming speaker this many seconds before they start, when the outgoing hold allows (default 0).
`overlap_min_seconds`	No	Minimum crosstalk length before the cover shot is used (default 0.6).
`cutaway_every_seconds`	No	Insert a cover cutaway during monologues longer than this many seconds (default: none).
`total_duration_seconds`	No	Plan end in sequence seconds (default: last segment end).

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether the tool completed successfully.
`data`	No	Tool-specific result data when ok is true; on failure, diagnostic detail when the tool provides it.
`tool`	Yes	The registered MCP tool name.
`error`	No	Failure detail when ok is false.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.19.1Oct 5, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds genuinely useful non-schema behavior: local-only execution, determinism, and that it never modifies Premiere — clarifying this is a planning artifact, not an applied edit. It stops short of timing or size-limit caveats.

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?

A single dense sentence that front-loads the action and its inputs before listing outputs, then closes with the key safety/determinism note. Everything earns its place, though the output enumeration is long.

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?

With an output schema present, return values need not be spelled out, and the description still summarizes them plus the read-only/local-only behavior. For a 12-parameter planning tool this is close to complete; only explicit sibling routing 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?

Schema description coverage is 100%, so the schema carries the parameter definitions and the baseline is 3. The description connects several parameters to their outcomes (minimum holds, crosstalk cover shots, lead-in cuts, periodic cutaways), which adds framing, but it does not define any parameter's units or defaults itself.

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?

Specific verb+resource: 'Plan active-speaker camera switching for stacked, synced camera tracks.' It enumerates exactly what is produced (angle cut list, razor times, enable/disable ranges, markers), which clearly distinguishes it from adjacent planning tools like plan_speaker_checkerboard and plan_active_speaker_reframe.

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

Usage Guidelines3/5

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

The description implies the precondition (speaker segments plus a camera-to-speaker map) and scope, but never states when to prefer this over sibling planning tools or when it is inappropriate. Usage is inferable rather than explicit.

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

Deploy Server