DaVinci Resolve MCP Server: giving Claude and Codex control of a live Resolve session

What samuelgursky/davinci-resolve-mcp actually connects

The project is a Model Context Protocol server that exposes DaVinci Resolve Studio to an AI assistant over the official Scripting API. The problem it addresses is narrow and real: Resolve's automation surface exists, but an assistant cannot reach it without a process that speaks both MCP on one side and Resolve's Python scripting objects on the other. This repository is that process. It is written in Python, licensed MIT, and published to npm as davinci-resolve-mcp, where the package is described as an "NPM bootstrapper for the DaVinci Resolve MCP Server" rather than the server itself. The npm entry point installs a managed copy and then runs the Python installer.

The intended user is a working editor or post-production engineer who already has Resolve open and wants an assistant to do bounded things inside it: inspect project state, reorganize the media pool, configure a render, place review markers, touch grading or Fusion or Fairlight nodes, and run source-safe analysis of media. The README frames the scope as "full API coverage plus guarded workflow helpers," and the repository carries a docs/reference/api-coverage.md file plus a test-results anchor, so coverage is treated as something to document rather than assert.

Two things about the framing are worth separating. The tool count is not the interesting claim. The interesting claim is the transport story below, because Resolve gates external scripting in a way that shapes every deployment decision you will make.

Two server modes and a second, file-level server

The README documents a compound mode and a granular mode. The compound server is src/server.py and exposes 36 tools, grouping related Resolve operations behind action parameters to keep context usage low. The granular server is src/server.py --full, or src/resolve_mcp_server.py, and exposes 353 tools, one per Resolve API method. The README's own recommendation is the compound server "unless you specifically need the granular one-tool-per-method surface." That is a sensible default: 353 tool definitions consume context before the assistant has done anything, and most editing tasks map onto grouped actions anyway. The cost is indirection, since you have to know which action parameter to set.

A third component sits outside the Python server. The same npm package ships davinci-resolve-advanced-mcp, with the bin entry bin/davinci-resolve-advanced-mcp.mjs. The README describes the split plainly: the Python server drives a live Resolve over the sanctioned scripting API, while the advanced server does what the API cannot, reading and editing Resolve files such as .drp, .drt and .drx and applying database or XML level changes. That is a different risk profile. Editing project files is not the same as calling methods on a running application, and the README's description of what the advanced server changes is brief, so treat it as a separate evaluation rather than a bonus feature.

The advanced server also carries a Python dependency: requirements.txt notes that pyaaf2 powers an offline AAF preview through editorial.parse_interchange with format "aaf" and list_sequences on an .aaf file, via server/aaf_probe.py, and that the installer points AAF_PROBE_PYTHON at the venv. Without pyaaf2 the AAF preview refuses rather than faking a result, and live AAF import into Resolve does not need it because Resolve reads AAF natively. That refusal behaviour is the right choice.

Installing davinci-resolve-mcp and running a first session

The documented quick start is a single npx command. It installs a managed copy under your user application-data directory and then runs the universal Python installer, which creates a virtual environment, detects Resolve paths, and can configure a long list of clients including Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Zed, Continue, Cline, Roo Code, OpenCode, Codex CLI and JetBrains IDEs.

npx davinci-resolve-mcp setup

Before the assistant connects, open DaVinci Resolve Studio and set Preferences > General > External scripting using to Local. The README is explicit that this preference does not help on the free edition, which is why the bridge below exists. If you prefer a source install, the README gives this sequence:

git clone https://github.com/samuelgursky/davinci-resolve-mcp.git
cd davinci-resolve-mcp
python install.py

For the free edition, install the in-app bridge and then launch it from inside Resolve. The README's steps are to run the installer script, restart Resolve, open a project, and pick Workspace > Scripts > resolve_bridge.

python scripts/install_resolve_bridge.py

Once that listener is running it is used automatically whenever external scripting is unavailable, with no environment variable required. Setting DAVINCI_RESOLVE_BRIDGE=1 forces the bridge so it becomes the only transport tried, which is what you want when the bridge is the path you intend to depend on, because a bridge that stops answering then reports its own fault instead of quietly falling back. On macOS, Resolve looks for Python 3 in exactly two places: the PYTHON3HOME environment variable, then /usr/local/bin/python3. Homebrew, pyenv, uv and conda land in neither, so the script silently never appears in the menu. The fix uses launchctl setenv rather than export, because Resolve is launched from the Dock and never sees your shell environment; restart Resolve afterwards.

launchctl setenv PYTHON3HOME "$(python3 -c 'import sys; print(sys.prefix)')"

The control panel is the first thing worth opening, because it shows Resolve state without going through an assistant. The README says to launch it from the repository root and that it starts a loopback-only server and opens a browser URL carrying a per-launch access token.

venv/bin/python -m src.control_panel

Use that exact URL, since the panel refuses requests without the token. Persisted analysis jobs refresh the local search index after successful slices, and the manual Build Index action exists for rebuilding from existing reports.

The free-edition bridge is the most interesting and least durable part

Blackmagic gates external scripting to Studio. On the free edition, scriptapp("Resolve") refuses a foreign process regardless of the preference setting. The Workspace > Scripts menu is not gated, so a script launched from it receives the live resolve object on any edition. The project's answer is a small script that runs inside Resolve and re-exports that object over an authenticated loopback listener, using HMAC-signed requests and one-use nonces.

The README calls this "the documented in-app path, not a licence circumvention," and then adds the sentence that should govern your planning: Blackmagic could close it, so treat it as a supported-until-it-is-not tier. That is an unusually honest framing, and it means the free-edition path should not sit under anything you cannot rebuild. The bridge also holds its port for as long as it serves. Before v2.70.3 a Windows bridge could outlive Resolve and block the next session's listener, so on an older build a bridge that stops answering may be a stale fuscript.exe still holding the port rather than a configuration error.

Platform validation is uneven in a way worth reading carefully. macOS was validated directly on free 21.0.3.7 and Studio 19.1.3.7. The Windows paths added in v2.70.1 shipped unverified, and reports on free 21.0.1.11 and free 21.0.3.7 have since shown the bridge installing, listing and serving from both %PROGRAMDATA% and %APPDATA% on Windows 11, so those paths are now confirmed rather than assumed. Linux is confirmed too: a report on free 20.3.2.9 on Fedora 43 shows the bridge installing to ~/.local/share/DaVinciResolve/Fusion/Scripts/Utility, listing against the system Python, and serving end to end. The README notes Linux has none of the interpreter discovery problem. The summary it gives is that no platform now rests on an assumption, with macOS validated directly and Windows and Linux on user reports. User reports are weaker evidence than direct validation, and the README says so itself.

Where this is the wrong tool

Every mode here depends on a running Resolve instance. If you want to render overnight on a machine with no application session, or to run a batch across a project archive on a build server, this is not the layer you want. The advanced server reads and edits .drp, .drt and .drx files, which is closer to headless work, but it is a separate server with a separate risk profile and the README documents it only briefly.

The dependency pinning is a second constraint. requirements.txt explains that server.py imports mcp.server.fastmcp, which the 1.x SDK provides, and that the 2.0.0 major restructured the SDK with no fastmcp module and a switch to httpx2. The installer runs pip install mcp[cli] unpinned first, so it grabs 2.0.0, and the constraint mcp[cli]>=1.30,<2 installed second pins it back. That works, but it is a two-step repair rather than a single pinned install, and anyone who manages the virtual environment by hand can end up on an incompatible SDK.

Finally, the granular mode is a trap for the unwary. 353 tools is a large context surface, and the README's own recommendation points away from it. Choosing it because it sounds more complete is the wrong reason.

Compared with driving Resolve from a plain Python script

The obvious alternative is what most Resolve automation already is: a Python script you write yourself against the Scripting API, run from the Workspace > Scripts menu or from a terminal with external scripting enabled. That approach has real advantages. It has no MCP layer, no virtual environment managed by an installer, no npm bootstrapper, and no transport negotiation, and it will keep working as long as the Scripting API does. For a fixed, repeated task such as a render preset or a media-pool naming convention, a script is less machinery and easier to debug.

The difference in approach is where the intelligence sits. A script encodes decisions you made in advance. The MCP server exposes Resolve's operations as tools so an assistant can decide at run time which ones to call, which is useful when the task is exploratory, for example inspecting a timeline before deciding what to organize or what to mark. If your task is already fully specified, the MCP layer adds a dependency chain without adding capability. If your task changes each time you sit down, the script approach means rewriting the script. That is the actual trade, and it has nothing to do with tool counts.

Maintenance, updates and the MIT licence

The repository is not archived, and the last push was on 2026-08-29, with v2.103.3 released the same day and v2.103.1 and v2.103.2 earlier that month. Recent release titles include one that reads "Windows setup that failed with nothing to read," which is a useful signal about the project's own bug cadence on Windows.

The installer and server check the latest GitHub release for MCP updates. The README states these checks are best-effort and throttled, and that the server never blocks MCP startup for a prompt. The installer can prompt, snooze, ignore a release, disable checks, or apply an opt-in safe auto-update for clean git checkouts. If you installed from npm rather than a git clone, the auto-update path does not apply to you, since it is scoped to clean checkouts.

The licence is MIT. That is permissive and places few obligations on how you redistribute or modify the code. It says nothing about Blackmagic's terms for DaVinci Resolve itself, and the free-edition bridge in particular depends on behaviour Blackmagic controls rather than on anything the MIT grant covers. This is not legal advice; if you plan to ship a product around this, the Resolve licensing question is separate from the repository's licence and worth checking on its own.

Editorial conclusion

Adopt it if you already run Resolve Studio on macOS and want an assistant to inspect state, organize the media pool, set up renders or drop review markers instead of clicking through menus, and if you accept that the free-edition bridge is a documented path Blackmagic could close. Do not adopt it if you need unattended automation on a headless machine, since every mode depends on a running Resolve instance, or if you are on a Resolve build older than the ones the project reports validating. Before wiring it into a real project, confirm that Preferences > General > External scripting using is set to Local, that the installed mcp package is below 2.0, and that your Resolve version matches one of the validated builds rather than assuming the API surface is identical.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes