Skip to main content
Glama
leancoderkavy

Premiere Pro MCP Server

Select Clips By Color

select_clips_by_color

Select all timeline clips whose source project item uses a specified color label. Choose a color index to isolate matching clips for batch editing.

Instructions

Select all clips whose source project item has a specific color label.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
color_indexYesLabel color index (0=Violet, 1=Iris, 2=Caribbean, 3=Lavender, 4=Cerulean, 5=Forest, 6=Rose, 7=Mango, 8=Purple, 9=Blue, 10=Teal, 11=Magenta, 12=Tan, 13=Green, 14=Brown, 15=Yellow)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesWhether the tool completed successfully.
dataNoTool-specific result data when ok is true; on failure, diagnostic detail when the tool provides it.
toolYesThe registered MCP tool name.
errorNoFailure detail when ok is false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.18.6
    • addedInput schema / additionalProperties
      Added value: +false
    • changedOutput schema / properties / data / description
      Previous value: -"Tool-specific result data when ok is true."New value: +"Tool-specific result data when ok is true; on failure, diagnostic detail when the tool provides it."
  2. Changed2 schema fields changedv1.14.4
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "https://json-schema.org/draft/2020-12/schema",
      +  "additionalProperties": false,
      +  "properties": {
      +    "data": {
      +      "description": "Tool-specific result data when ok is true."
      +    },
      +    "error": {
      +      "description": "Failure detail when ok is false.",
      +      "type": "string"
      +    },
      +    "ok": {
      +      "description": "Whether the tool completed successfully.",
      +      "type": "boolean"
      +    },
      +    "tool": {
      +      "description": "The registered MCP tool name.",
      +      "minLength": 1,
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "ok",
      +    "tool"
      +  ],
      +  "type": "object"
      +}
  3. Changed1 schema field changedv1.4.0
    • removedInput schema / additionalProperties
      Removed value: -false
  4. First observedv1.1.1

TDQS

B3.3/5.0
Behavior3/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the agent knows this changes state but destroys nothing. The description adds no behavioral context beyond that, notably whether the selection replaces or extends the current selection — the key semantic for a select tool, especially with idempotentHint=false.

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

Conciseness5/5

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

A single sentence that front-loads the action and never wastes a word. Appropriately sized for a one-parameter filter tool.

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?

An output schema exists, so return values need no explanation, and the single parameter is fully documented in the schema. The remaining gap is selection semantics — replace vs. additive, and behavior on no match — which is not covered anywhere given idempotentHint=false.

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% and the color_index parameter is fully documented in the schema with an explicit index-to-color mapping, so the description correctly need not repeat it. The phrase 'specific color label' mirrors the parameter but adds no format or range detail.

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 verb (select) and resource (clips) filtered by a named attribute (color label on source project item), which distinguishes it from generic selection tools. However it does not explicitly differentiate from the nearby siblings select_clips_by_name and select_clips_by_pattern, which follow the same pattern.

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?

No when-to-use or when-not-to-use guidance, and no routing to alternatives such as select_clips_by_name, select_clips_by_pattern, or select_all_clips. The agent must infer the choice between the family of selection tools entirely on its own.

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