Premiere Pro MCP Server

Preview After Effects Render Handoff

preview_after_effects_render_handoff

Read-onlyIdempotent

Preview importing a completed After Effects single-file render into an existing Premiere bin. It validates host projects, file metadata, and bin identity before approval.

Instructions

Preview import of one completed After Effects single-file render into an existing Premiere bin. Reads both connected hosts and binds approval to file metadata and project/bin identity. Does not render, import, or edit a timeline.

Input Schema

TableJSON Schema

Name	Required	Description
`output_path`	Yes	Existing completed .mov, .mp4, .mxf, .avi or .wav render; image sequences are not supported.
`target_bin_id`	Yes	Exact node ID of an existing destination bin, never a name.
`ae_project_path`	Yes	Exact open, saved After Effects project path.
`queue_item_index`	Yes	One-based AE render queue item index, as returned by enqueue_after_effects_render.
`premiere_project_path`	Yes	Exact open, saved Premiere project path. It may be outside approved_workspace_path: it is only compared with the project Premiere has open.
`approved_workspace_path`	Yes	Existing absolute workspace containing both saved projects and the rendered media.

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.

Changed2 schema fields changedv1.18.6Sep 30, 2026

changedInput schema / properties / premiere_project_path / description

Previous value: -"Exact open, saved Premiere project path."New value: +"Exact open, saved Premiere project path. It may be outside approved_workspace_path: it is only compared with the project Premiere has open."

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."

Addedv1.14.9Sep 8, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds substantive context beyond that – it reads both connected hosts, binds approval to file metadata plus project/bin identity, and enumerates the operations it does NOT perform. It stops short of explaining what an approval result or invalidation looks like.

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?

Three tight sentences, front-loaded with the operation and scope, followed by the binding behavior and then the explicit non-goals. Nothing is padding and each sentence adds a distinct fact.

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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. The description supplies scope, host-read requirement, and negative constraints, giving an agent enough to invoke it correctly; only the meaning of 'binds approval' and the relationship to the apply tool remain implicit.

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 coverage is 100% with all six parameters documented in their own descriptions, including the constraints that matter (one-based queue index, exact bin node ID, existing open projects). The description adds only the general 'single-file render' framing and does not supplement parameter semantics beyond what the schema already provides.

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 (preview import) plus resource scope (one completed single-file After Effects render into an existing Premiere bin), which concretely distinguishes it from the sibling apply_after_effects_render_handoff and from preview_mogrt_premiere_handoff. The file-type and single-item scope further sharpen what is being previewed.

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 this is the dry-run step preceding an apply/handoff, and it explicitly excludes rendering, importing, and timeline editing. But it never names the alternative tool or states the condition that selects preview over apply, so the agent must infer the workflow position.

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

Deploy Server