Skip to main content
Glama

pr_getClipProperties

Read-only

Retrieves all effect components on a Premiere Pro clip—including parameters, values, and keyframes—so you can inspect Motion, Opacity, Volume, Lumetri, and plugin settings.

Instructions

Premiere Pro: every effect component on a clip with its parameters, values and keyframes (Motion, Opacity, Volume, Lumetri, plugins...).

Input Schema

NameRequiredDescriptionDefault
clipYesA timeline clip: {track:"V1", clip:2} (1-based on that track), {track:"V1", clip:"name"}, or {track:"V1", time:12.5}.
sequenceNoSequence name; omit for the active sequence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine value by disclosing the return breadth (all effect components, not just transform) and that keyframe data is included — information an agent cannot get from annotations and that matters when deciding whether this call is expensive or sufficient.

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 compact sentence with the resource and the enumerated component types front-loaded. Only the 'Premiere Pro:' app prefix is arguably redundant with the tool's pr_ prefix.

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?

With no output schema, the description must carry return-value information, and it does say what categories come back. However, it leaves the shape of the response unknown — how components, parameters and keyframe arrays are nested — and says nothing about behavior when the clip reference does not resolve, which matters for a nested-object-parameter read tool.

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%: the nested clip object documents track/clip/time addressing and the sequence parameter documents the active-sequence default. The description adds nothing about how the clip or sequence arguments behave, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and scope: every effect component on a clip, with parameters, values and keyframes, and names concrete component types (Motion, Opacity, Lumetri, plugins). An agent can distinguish it from the mutating pr_setClipProperties and from sequence-wide pr_getSequenceState, though the description never names those siblings explicitly.

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

Usage Guidelines2/5

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

There is no when-to-use / when-not-to-use guidance and no mention of alternatives such as pr_getSequenceState, pr_getSelection or pr_findEffects. The read-only nature implies inspection, but the routing decision is left entirely to the agent's inference.

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

Deploy Server

Other Tools