DaVinci Resolve MCP Server: Full API Coverage, a Free-Edition Bridge, and a 353-Tool Mode

What It Solves and Who It Is For

The server solves a specific mismatch: DaVinci Resolve Studio's official Scripting API is powerful but not shaped for conversational use. An AI assistant cannot easily know which of the hundreds of API methods to call for a compound task like 'set up a render' or 'organize the media pool'. This MCP server wraps that API into two surfaces: a compound mode with 36 tools that group related operations behind action parameters, and a full mode with 353 tools, one per API method. The intended user is an editor or post-production engineer who wants Claude, Cursor, VS Code, or another MCP client to operate Resolve directly, rather than through a series of manual clicks. The README also mentions extension authoring and source-safe media analysis, which broadens the audience to developers building Resolve extensions. The npm launcher and the Python installer both target people who are comfortable with command-line setup, not casual users.

How the Server Works: Compound vs Granular Modes

The core mechanism is a Python server that talks to a live Resolve instance over the Scripting API. The compound mode, started with `src/server.py`, exposes 36 tools. The README says related operations are grouped behind action parameters to keep context usage low. That is a meaningful design choice: an AI client has limited context windows, and 353 separate tool definitions would consume a large portion of that context before any real work happens. The granular mode, started with `src/server.py --full` or `src/resolve_mcp_server.py`, gives one tool per API method. The README recommends the compound server unless you specifically need the granular surface. The trade-off is clear: compound tools are easier for an assistant to reason about, but they may not expose every parameter of every API method. Granular tools are complete but noisy. The server also ships a local control panel, started with `venv/bin/python -m src.control_panel`, which runs a loopback-only server and opens a browser at a URL with a per-launch access token. The panel refuses requests without that token, which is a sensible security boundary for a tool that can read and edit your project.

Getting It Running: Commands and Config Keys

The quick start is a single command: `npx davinci-resolve-mcp setup`. The npm launcher installs a managed copy under your user application-data directory, then runs a universal Python installer. That installer creates a virtual environment, detects Resolve paths, and can configure a long list of clients: Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Zed, Continue, Cline, Roo Code, OpenCode, Codex CLI, and JetBrains IDEs. For source installs, you clone the repository and run `python install.py`. Before connecting, you must open DaVinci Resolve Studio and set Preferences > General > External scripting using to Local. On the free edition, that preference does not help, because Blackmagic gates external scripting to Studio. The installer and server check the latest GitHub release for MCP updates, but the checks are best-effort and throttled, and the server never blocks MCP startup for a prompt. You can prompt, snooze, ignore a release, disable checks, or opt into a safe auto-update for clean git checkouts. That auto-update option is worth noting: it only applies to clean git checkouts, so if you have local modifications, you should not enable it.

The Free-Edition Bridge: How It Works and Its Risks

The most interesting part of the project is the in-app bridge for the free edition. Blackmagic gates external scripting to Studio, but the Workspace > Scripts menu is not gated. A script launched from that menu is handed the live `resolve` object on any edition. The bridge exploits that: you run `python scripts/install_resolve_bridge.py`, restart Resolve, open a project, then select Workspace > Scripts > resolve_bridge. That script runs inside Resolve and re-exports the resolve object over an authenticated loopback listener. The server then uses that listener automatically whenever external scripting is unavailable. You can force the bridge with `DAVINCI_RESOLVE_BRIDGE=1`, which makes it the only transport tried. That is a useful debugging feature: if the bridge stops answering, you see its fault rather than a silent fallback. The security design is loopback only, HMAC-signed requests, and one-use nonces. The README is explicit that this is a documented in-app path, not a licence circumvention, but Blackmagic could close it. That is a genuine limitation. The bridge also holds its port for as long as it serves, and before v2.70.3 a Windows bridge could outlive Resolve and block the next session's listener. If you are on an older build and a bridge stops answering, the README suggests checking for a stale `fuscript.exe` holding the port.

Platform-Specific Setup Traps, Especially macOS and Windows

The bridge has platform-specific quirks that are documented in detail. 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 bridge script silently never appears in the menu. The fix is to point Resolve at your existing interpreter with `launchctl setenv PYTHON3HOME "$(python3 -c 'import sys; print(sys.prefix)')"`. The README stresses using `launchctl setenv`, not `export`, because Resolve is launched from the Dock and never sees your shell's environment. A Lua canary is installed alongside so you can tell 'Python not detected' apart from a wrong folder. On Windows, the paths added in v2.70.1 shipped unverified, and the README notes that a release v2.103.2 was a Windows setup that failed with nothing to read. Later user reports on free 21.0.1.11 and 21.0.3.7 confirmed the bridge installing, listing, and serving from both `%PROGRAMDATA%` and `%APPDATA%` on Windows 11. Linux is confirmed as well, via a report on free 20.3.2.9 (Fedora 43), where the bridge installs to `~/.local/share/DaVinciResolve/Fusion/Scripts/Utility`. The README claims no platform now rests on an assumption, but macOS was validated directly, while Windows and Linux rest on user reports. That is a distinction worth remembering if you are on a less common Linux distribution.

The Optional Advanced Server: What It Does and What It Cannot Do

The package also ships a second, optional MCP server called `davinci-resolve-advanced-mcp`, with a bin at `bin/davinci-resolve-advanced-mcp.mjs`. The README explains the difference: the Python server drives a live Resolve over the sanctioned scripting API, while the advanced server does what the API cannot. It reads and edits Resolve files such as `.drp`, `.drt`, and `.drx`, and applies DB/XML-level changes with no Resolve running. The material is truncated right after that sentence, so the full feature set is not visible. That is a limitation for this review, but the architectural difference is clear. If you need to manipulate project files without opening Resolve, the advanced server is the intended tool. If you need to control a live session, the Python server is the one to use. The Node-based server is separate, so you would need to install and configure it independently. The README does not give a quick start for it in the visible portion, so you should check the docs directory for installation details.

Maintenance, Upgrades, and Licence Implications

The project is under the MIT license, which means you can use, modify, and redistribute it with few restrictions, though this is not legal advice. The repository is not archived and had a push in August 2026, with releases v2.103.3, v2.103.2, and v2.103.1 around that date. The release cadence suggests active maintenance, but the v2.103.2 release note is a warning: a Windows setup that failed with nothing to read. That means the project ships releases that can be broken, so you should check the release notes before upgrading. The installer has an update-check mechanism that is best-effort and throttled, and it can prompt, snooze, ignore, disable, or auto-update. The auto-update only applies to clean git checkouts, which is a safe constraint. The server itself never blocks MCP startup for a prompt, so a slow network or a missing update check will not stall your assistant. The bridge's dependency on a loopback listener means you need to manage that process carefully, especially on Windows where a stale process can block the port. The README's note about the bridge holding its port for as long as it serves is a maintenance cost you should plan for.

Editorial conclusion

Adopt this server if you run DaVinci Resolve Studio, want AI assistants to drive editing, media pool, render, grading, Fusion, Fairlight, or project lifecycle tasks, and you are comfortable with a Python installer that manages its own virtual environment. Do not adopt it if you need a stable path for the free edition: the bridge relies on a loopback listener that Blackmagic could close, and the README calls it a supported-until-it-is-not tier. Before relying on the bridge, verify your platform: macOS was validated directly, but Windows and Linux rest on user reports, and the Windows bridge had a stale-process bug fixed only in v2.70.3. Also check the release notes for your version, because v2.103.2 shipped a Windows setup that failed with nothing to read. If you need file-level edits to .drp or .drx files, the optional Node-based advanced server exists, but its documentation is truncated in the material, so verify its current capabilities separately.

Official sources

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