premiere-pro-mcp

Overview Schema Source Related Servers Discussions Admin

Paste Clip Attributes

paste_clip_attributes

Copies a timeline clip's effect stack and keyframes onto another clip on the same track type, then reports each pasted parameter as verified, unverified, or failed.

Instructions

Paste Attributes for one timeline clip: copy the source clip's effect stack (Motion, Opacity, other intrinsic components, and every applied effect) onto a target clip of the same track type, including keyframes. Components are matched by match name and occurrence; a missing non-intrinsic effect is applied through the experimental legacy QE DOM (disable with apply_missing_effects=false). Every written parameter and keyframe value is read back and reported per property as verified, committed_unverified, or failed, with an overall status. Not copied, and listed in notCopied with a reason: parameters whose values ExtendScript cannot read as numbers, booleans, strings, or numeric arrays; Opacity > Blend Mode when it differs (legacy cross-clip enum writes can corrupt it; use set_blend_mode and verify); and keyframe interpolation (no getter exists, so pasted keys use Premiere's default interpolation). MASKS ARE NOT COPIED: neither ExtendScript, QE, nor documented Premiere UXP exposes mask shapes, paths, feather, expansion, or mask keyframes, and masks are invisible to this bridge, so recreate or paste masks manually in Effect Controls. Time Remapping is excluded unless named in components.

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": {
      "source_node_id": "<source_node_id>",
      "target_node_id": "<target_node_id>"
    },
    "name": "paste_clip_attributes"
  }
}

Input Schema

Name	Required	Description
`components`	No	Optional component display names or match names to copy (for example ['Motion', 'Opacity', 'Gaussian Blur']). Omit to copy every source component except Time Remapping.
`copy_keyframes`	No	Copy keyframes of animated source properties (default true). Key times keep their offset from each clip's in point. When false, animated source properties are reported in notCopied and left unchanged on the target.
`source_node_id`	Yes	Node ID of the source timeline clip in the active sequence whose attributes are copied
`target_node_id`	Yes	Node ID of the target timeline clip in the active sequence that receives the attributes; must be on the same track type (video or audio) as the source
`idempotency_key`	No	Optional 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_target`	No	Optional reviewed CEP sequence/clip identity and exact tick ranges. Checked before every generated command; UXP refuses this CEP-only guard.
`apply_missing_effects`	No	Apply source effects that the target lacks through the experimental legacy QE DOM before copying values (default true). When false, missing effects are reported in notCopied.
`expected_project_path`	No	Optional 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.

Output 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.
`receipt`	No	Versioned common mutation receipt; success never implies rendered verification.
`idempotency`	No	Present 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.

First observedv1.30.0Nov 14, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false, idempotentHint=false — the description adds substantially: per-property read-back verification with three outcome statuses, the fallback to the experimental legacy QE DOM, and the notCopied list with per-item reasons. It explicitly discloses the surprising side effects (default keyframe interpolation, missing mask support, cross-clip enum corruption risk), which is exactly the behavioral context annotations don't carry.

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?

Front-loaded with the core action and copy scope, then organized into exclusion categories separated by semicolons. It is dense and lengthy, but nearly every clause carries operational information (the mask caveat, the blend-mode corruption warning, the interpolation default). Minor cost in readability from capitalization emphasis rather than structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with nested objects and rich behavior, the description covers the mutation semantics, partial-failure reporting, fallback paths, and hard limitations. An output schema exists so return values need not be specified, yet the description still explains the verification status vocabulary, which is the friction point an agent would otherwise stumble on.

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?

Schema coverage is 100%, so the baseline is 3; the description goes beyond by explaining what components does by default ('every source component except Time Remapping'), how match-name/occurrence matching works, and what apply_missing_effects toggles in terms of the QE DOM path. It does not add much about source_node_id, target_node_id, or expected_cep_target, but the high-risk parameters are covered.

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?

States a specific verb and resource ('copy the source clip's effect stack ... onto a target clip of the same track type') and enumerates exactly what is included (Motion, Opacity, intrinsic components, applied effects, keyframes). It names the related siblings set_blend_mode and set_clip_opacity by implication of what it does not do, so an agent can distinguish it from those tools without opening their schemas.

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 concrete routing guidance: use set_blend_mode for blend-mode values, name Time Remapping in components to include it, disable apply_missing_effects to avoid the experimental QE path, and recreate masks manually in Effect Controls. It lacks an explicit negative case for when not to use paste_clip_attributes at all (e.g., across track types), but the same-track-type constraint and the alternatives embedded in the exclusions give strong selection context.

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

Deploy Server