davinci-resolve-mcp: one installer for twelve editors, a dependency pinned back after being installed wrong on purpose, and a bridge into the free edition

The repository description contains raw badge text from a copy and paste

The one-line description for this repository reads like three sentences mashed together: a claim that it is an integration for the studio edition, then a fragment of a shields.io badge with its file name and its percent-encoded colour value still in it, then the real description of what it is. The same thing happened inside the README, where the badge images have been stripped and what remains in their place is a set of empty links and two fragments of badge alt text, one of which still contains the encoded colour string. The result is a document whose opening navigation is a row of link targets pointing at an API coverage page and at two headings that no longer carry images. None of it affects the code, and all of it is the kind of thing that tells a reader the metadata and the badges were assembled somewhere else and pasted in without review.

One installer configures twelve editors, and manages its own copy

The quick start is one command:

npx davinci-resolve-mcp setup

The quick start is one command through the Node package registry, and what it does is worth reading rather than running. It installs a managed copy of itself under the user application data directory, then hands off to a Python installer that creates a virtual environment, detects where the editor is installed, and can write configuration for eleven clients: two Claude surfaces, three of the common editors, an editor built around agents, a terminal-first client, two agent extensions, a fork of one of them, a coding agent, the Codex command line tool and the JetBrains family. So one command edits configuration for a dozen pieces of software on your machine, and it installs a copy of itself before doing any of it. The project documents a source route as well, a clone and a Python install script, and points at a separate document for platform paths and manual configuration when the automatic path guesses wrong.

The update check must never delay startup, and the design says so

Both the installer and the running server check the project's own releases for newer versions, and the README is explicit about the constraint that shapes it: checks are best-effort and throttled, and the server never blocks startup waiting for a prompt. That matters because a protocol server sits between an assistant and a running desktop application, and a network round trip at startup is a hang the user cannot explain. So the check is non-blocking by requirement rather than by accident. The installer is allowed to prompt, to snooze, to ignore a release, to turn checks off entirely, or, on a clean checkout, to apply an opt-in automatic update. The opt-in framing is the careful part: the automatic path is offered only where the working tree is unmodified, which is the condition under which an update cannot destroy local work.

The bridge reaches the free edition through a script running inside Resolve

The vendor gates external scripting to the studio edition, so on the free edition the ordinary connection is refused by the application itself, whatever the preference says. The project documents a second path. Through the 21.0 line, the in-application Scripts menu was not gated: a script launched from that menu is handed the live application object, so the server can reach the free edition through a small script that runs inside the editor and re-exports that object over an authenticated loopback listener. The README states this is the documented in-application path and not a licence circumvention, and then says the vendor could close it and to treat it as supported until it is not, which is the honest way to describe a workaround. From the 21.1 line the vendor moved Python scripting to the studio tier, so on the free edition the menu no longer lists those scripts at all, and the project tells readers to treat the bridge as a 21.0 path until that is measured again. The security properties it claims for the listener are narrow and specific: loopback only, signed requests, and nonces that work once.

On macOS, Resolve looks for Python in exactly two places

One paragraph in the README is the most useful operational documentation in the repository. On macOS, the editor looks for a Python 3 interpreter in exactly two locations: an environment variable, and one fixed path in a local bin directory. Version managers and alternative installers land in neither, and the symptom is silence: the script simply never appears in the menu. The documented fix sets the environment variable through a session launcher rather than a shell export, because the editor is launched from the dock and never sees your shell environment, and the README says so explicitly. Two more traps follow. The prefix you point at must contain both the shared library and an unversioned interpreter name, so a framework build that ships only a versioned name is half a Python as far as the editor is concerned, and the installer's preflight now says that instead of reporting success. And the session setting does not survive a reboot, so scripts that stop listing weeks later with no error have a known cause.

Platform support is sorted into measured, reported and assumed

Rather than a support table, the README tells you how it knows what it knows. It was measured directly on two editor versions on macOS, one free and one studio. The Windows paths were added in an earlier version and shipped unverified, and are now confirmed by two user reports on Windows 11 showing the bridge installing from two different data locations and serving. Linux is confirmed by one report on Fedora, which also notes that Linux has none of the interpreter discovery problem because the system interpreter is already where the editor looks. Then the sentence that makes the whole passage useful: no platform now rests on an assumption. There is also a version-specific warning with a process name in it, that a bridge on an older Windows build can outlive the application and keep holding its port, so a bridge that stops answering may have a stale executable behind it rather than a bug in the server.

The Python requirements install an incompatible major and then pin it back

The Python requirements file has two entries and both comments are longer than the entries. The first explains why an offline reader for the professional interchange format is installed at all: it powers a preview that works without the editor, and without the reader that preview refuses rather than faking a result, which is a sentence worth having in a dependency file. The second explains a deliberate two step install. The server imports a module that only the first major of the SDK provides; the second major restructured it and dropped that module. The comment then says the installer runs the install command for that dependency unpinned first, so it fetches the incompatible major, and that the constraint in the requirements file is installed second in order to pin it back. That is honest and unusual, and it is also a window in which the wrong version is resolved and installed on every fresh machine before being corrected.

Ten agent configuration directories, a committed colour cube, and a log directory

The repository root shows what it takes to be this project's user and its maintainer at once. There are ten separate instruction directories and files for coding assistants, one per client, which is also a neat proof that the automatic configuration covers the tools it claims to. There is a colour lookup file with a cube extension sitting at the top level of the server's own repository, which is a Resolve project asset rather than server source, and a logs directory tracked alongside the code. The package ships a long file list that includes the vendor's own scripting interface reference as a text file, a vendored directory for the second server, the Python sources, the installer, the documentation and two assistant instruction files. The Node manifest itself describes the package as a bootstrapper, and its only two scripts are a smoke test that asks the command for help and version, and a dry-run of the packaging step.

Editorial conclusion

davinci-resolve-mcp fits an editor user who wants their assistant inside the application and is comfortable with a server that installs itself and checks for updates. Four things to know. Two servers ship under two command names, and the package is described as a bootstrapper rather than the server itself. The installer configures eleven editors and assistants at once, which is convenient and broad. The bridge that reaches the free edition is documented by the project as a path the vendor could close at any time, and it stops working from the release where the vendor moved Python scripting behind the paid tier. And the Python requirements contain a deliberate two step install that grabs an incompatible major first, which is worth knowing before you trust an install log.

Frequently asked questions

Official sources

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