Skip to main content
Glama
Sign In
premiere-pro-mcp

premiere-pro-mcp

by matt-j-penny
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Delete Sequence

delete_sequence
Destructive

Deletes a sequence from an open Premiere Pro project and confirms it is gone; nested sequences are refused unless you explicitly confirm removing them from other timelines.

Instructions

Delete a sequence from the project and read back that it is gone. A sequence nested on another timeline is refused unless confirm_remove_from_sequences is true, matching delete_project_item; deleting it would remove or orphan those nested clips.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sequence_id": "<sequence_id>"
    },
    "name": "delete_sequence"
  }
}

Input Schema

NameRequiredDescriptionDefault
sequence_idYesSequence name or ID to delete
idempotency_keyNoOptional client-chosen key (1-128 chars of A-Z a-z 0-9 . _ : -) for this intended edit. Pass a fresh key per edit and reuse it only when retrying that same edit, for example after a client-side timeout. A repeat with the same tool, key and arguments is not run again: while the first call is running it fails with IDEMPOTENCY_IN_PROGRESS (poll get_last_operations); after it finished it returns the original outcome marked replayed. A definite failure with nothing applied (receipt outcome not_applied) may be retried with the same key. Reusing a key with different arguments fails with IDEMPOTENCY_KEY_REUSED. Scoped to this MCP session (the stdio server process, or the HTTP server process when Streamable HTTP is stateless per request) and held in memory only (200 keys, 1 hour); it does not survive a restart or reconnect. Read-only invocations are never deduplicated.
expected_cep_targetNoOptional reviewed CEP sequence/clip identity and exact tick ranges. Checked before every generated command; UXP refuses this CEP-only guard.
expected_project_pathNoOptional absolute saved-project path. Every generated CEP command refuses before its body when the active project differs or is unsaved. UXP commands refuse this CEP-only guard; local-only tools do not inspect Premiere. Omit to keep existing behavior.
confirm_remove_from_sequencesNoDelete even when this sequence is nested on another timeline, which also removes those nested clips (default: false).

Output 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.
receiptNoVersioned common mutation receipt; success never implies rendered verification.
idempotencyNoPresent when idempotency_key deduplicated this call: replayed is true when the original outcome was returned instead of running again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.30.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known; the description adds the non-obvious consequence of overriding the guard (nested clips removed or orphaned) and notes a readback verification step. It does not mention the idempotency_key retry/dedup behavior or the CEP/project-path guards, which live only in the schema.

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?

Two sentences, no filler: the core action and readback come first, then the guard condition and its consequence. Each clause carries information an agent needs before calling a destructive tool.

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-value detail is unnecessary, and the description covers the main destructive risk and refusal path for a 5-parameter tool with nested guards. Minor gaps remain around the idempotency contract and the CEP/project-path preconditions, though those are fully specified in the schema.

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 every parameter including confirm_remove_from_sequences and idempotency_key is already documented in the schema. The description restates the confirm flag's effect without adding syntax, defaults, or format detail beyond it, so the baseline of 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?

The description opens with a specific verb and resource ('Delete a sequence from the project') plus a post-condition ('read back that it is gone'). It does not name an alternative sibling such as delete_project_item or delete_bin for routing, but it references delete_project_item to signal consistent nested-item semantics, which is enough for an agent to identify the operation.

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?

It gives a concrete conditional rule: a sequence nested on another timeline is refused unless confirm_remove_from_sequences is true. That tells the agent when the call will fail and how to proceed. It stops short of explicit when-to-use-this-vs-sibling guidance (e.g., deleting a bin vs. a sequence).

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