Adobe Premiere Pro MCP: driving a local Premiere project from Claude, Codex or Cursor

The gap this fills: an agent that can only talk, not cut

Most MCP servers wrap a web API. This one wraps a desktop application that has no API in the ordinary sense. Premiere Pro exposes scripting through CEP and UXP extensions, and those run inside the application process on the editor's own machine. The project's answer is a local MCP server written in TypeScript plus a CEP panel that acts as the bridge into Premiere. The README states the supported bridge is the included CEP panel, and that UXP remains experimental. That single sentence sets the audience: editors and assistant editors who already work in Premiere and want an agent to handle the mechanical parts of a timeline, not studios looking for a rendering service. The npm package name is `adobe-premiere-pro-mcp`, the binary is `premiere-pro-mcp`, and the licence is MIT.

How the bridge works: a small always-on toolset over a 283-tool catalog

The architecture has three layers. Premiere Pro hosts the CEP panel. The panel talks to a local Node.js MCP server. The MCP client (Claude Desktop, Claude Code, Codex, Cursor, GitHub Copilot in VS Code) talks to that server. The interesting design decision is what the client sees by default. According to the README, `tools/list` advertises a small always-on set: `search_tools`, `get_tool_schema`, `invoke_tool`, `verify_premiere_connection` and `list_sequences`. The remaining operations sit in a catalog of 283 tools and are reached by calling `search_tools` and then `invoke_tool`. Setting `PREMIERE_MCP_TOOLSET=full` lists every tool instead, which the README notes is what Claude Code native tool search indexes. That is a deliberate trade: a few always-on tools keep the context window small, but the agent has to discover the rest at runtime, and discovery costs a round trip. The catalog itself spans project setup, media ingest, bins, sequences, timeline editing, transitions, effects, keyframes, captions, markers, metadata, proxies, multicam, color, audio and exports. The README also mentions 13 context resources and 10 guided prompts.

Installing the CEP bridge and running a first verification

The README's recommended path installs the npm package globally, then uses the CLI to install the CEP bridge and check the environment. `--install-cep` installs the CEP bridge, enables the required Adobe CEP debug setting, prepares the bridge directory and configures supported local MCP clients. `--doctor` verifies the server build, the CEP installation, the bridge directory, the debug setting and the client configuration.

npm install -g adobe-premiere-pro-mcp
premiere-pro-mcp --install-cep
premiere-pro-mcp --doctor

After that you restart Premiere Pro, open `Window > Extensions > MCP Bridge (CEP)`, set the bridge directory the installer showed you, and start the bridge. Requirements are Node.js 20 or newer, Adobe Premiere Pro 2020 or newer, and Premiere, the MCP client and this package all on the same computer. For a client the installer does not configure, the README gives this server entry, which you place in your MCP client's config.

{
  "mcpServers": {
    "premiere-pro": {
      "command": "premiere-pro-mcp"
    }
  }
}

The first real use is not an edit. It is a read-only check. The README's own instruction to Claude is to run `verify_premiere_connection` and make no changes. Do that before you let an agent touch a sequence, because it tells you whether the panel, the bridge directory and the server are actually talking to each other. The README's start-here line repeats the same order: install the bridge, open it in Premiere, then run `verify_premiere_connection` before editing.

Where the setup breaks: unsigned bundles, a debug setting and a same-machine rule

Three constraints are stated plainly and each one is a real failure mode. First, the MCPB bundle shipped with each GitHub release for Claude Desktop is unsigned, and the README tells you to install it only from the repository's GitHub Releases. CEP release archives are labelled as unsigned or self-signed, and the README is explicit that self-signed does not mean Adobe Marketplace trusted. If your organisation requires signed extensions, this is the wrong tool. Second, `--install-cep` enables the Adobe CEP debug setting. That is a change to your Adobe configuration, not a hidden one, but it is a change. Third, everything must be on one computer: Premiere Pro, the MCP client and the package. There is no remote or headless mode described. If your editors work on laptops and your agents run on a build server, the architecture does not fit. The README also notes the bundled `uxp-plugin` is an experimental preview, is shipped for evaluation, is not a replacement for the validated CEP bridge, and is not installed by the CLI. Treat any UXP-based plan as unvalidated.

CEP versus UXP, and how this differs from a script-based pipeline

The obvious alternative is writing your own ExtendScript or UXP panel, or driving Premiere through a conventional automation tool. The difference is not the editing capability, since both end up calling Premiere's scripting layer. It is the interface. A hand-written panel gives you exactly the operations you wrote and nothing else, and you own every bug. This project gives you a catalog of 283 tools, 13 context resources and 10 guided prompts, plus a discovery mechanism so an MCP client can find the right one by description rather than by you wiring each call. The cost is indirection: the agent calls `search_tools`, reads a schema, then calls `invoke_tool`, and each of those is a step that can pick the wrong tool. The README's own framing of CEP as production and UXP as experimental is the honest summary of where the validated path sits. If you only ever need three operations, a small custom panel is less machinery. If you want an agent to explore the timeline and pick operations itself, the catalog is the point.

Telemetry, licence and what an upgrade costs you

The package sends anonymous usage telemetry by default, and you opt out by adding an environment variable to the server entry in your MCP client config. The README points to PRIVACY.md and TERMS.md for the details, so read those rather than assuming. The licence is MIT, which permits commercial use and modification, and the repository ships LICENSE.md. That is a permissive licence, but it says nothing about Adobe's own terms for Premiere Pro, CEP extensions or the Adobe debug setting you enable during install, and those are separate agreements you already have with Adobe. On upgrades: the project publishes frequently, with v1.2.8, v1.2.7 and v1.2.6 all released within a few days of each other in late August and early September 2026, and the last push to the repository was on 2026-09-03. Fast releases mean you should pin a version rather than install globally and forget it, because the CEP panel and the npm package are installed as a pair and a mismatched pair is a plausible source of bridge failures. The CLI has `--doctor` for exactly that check, and the package scripts include `setup:doctor` and `setup:doctor:win` for source installs. There is also a CHANGELOG.md and a KNOWN_ISSUES.md in the repository, which is where you would look before filing anything.

What the README does not tell you

Several things a cautious adopter would want are absent from the documentation. There is no documented rollback procedure for `--install-cep`, so if enabling the CEP debug setting or writing the bridge directory causes trouble, the README does not describe how to undo it. There is no stated per-operation permission model: the catalog includes timeline editing, exports and metadata changes, and the only guardrail described is asking the agent to run a read-only verification first. That is a prompt-level guardrail, not an enforced one. The README does not document rate limits, concurrency behaviour, or what happens if two MCP clients drive the same Premiere session at once. It also does not state which of the 283 tools are validated on Windows versus macOS beyond the general note that the repository is validated for macOS and for Windows installer and config smoke checks through GitHub Actions. Smoke checks on an installer are not the same as a tool being exercised against a real timeline. If you are on Windows and your workflow depends on a specific operation, test that operation yourself before building a process around it.

Editorial conclusion

Adopt it if you already run Premiere Pro 2020 or newer on the same machine as your MCP client and you want an agent to do repetitive assembly, caption reads or export prep rather than creative cutting. Do not adopt it if you need a headless render farm, a cloud pipeline, or a signed, Adobe-trusted extension, because the bridge is a local CEP panel and the MCPB bundle ships unsigned. Verify three things before trusting it with a real project: that `premiere-pro-mcp --doctor` passes on your machine, that `verify_premiere_connection` returns clean with no changes requested, and that the tool you intend to call appears in the catalog after `search_tools`. If any of those three fail, the problem is the bridge, not the prompt.

Frequently asked questions

Official sources

1. hetpatel-11/Adobe_Premiere_Pro_MCP on GitHub
2. License: MIT
3. Project website
4. README
5. Releases