This server gives AI assistants on-demand access to the full DaVinci Resolve scripting API through a small always-available kernel and activatable domain tools.
Kernel tools (always available): Get Resolve version, get/switch current page, list domains, activate/deactivate domains.
Domain activation: Load tools on demand across 9 domains — project management, timeline operations, media pool, clip properties, color grading, render/delivery, Fairlight storage, timeline item editing, and AI studio.
Full API coverage: 289 total tools become available after activating relevant domains, covering opening/saving projects, managing timelines/tracks/markers, editing media pool clips, color grading, rendering, and more.
Efficient token usage: Only 6 tool definitions load at session start, so context costs stay low until you expand capabilities.
Safety for destructive operations: Deleting/modifying permanent data requires explicit confirmation arguments to prevent accidental damage.
Exposes the full range of functionality of DaVinci Resolve and DaVinci Resolve Studio to MCP clients, enabling programmatic control and integration with the video editing software.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DaVinci MCP Professional add a cross dissolve transition between the last two clips on the timeline"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An enterprise-grade Model Context Protocol (MCP) server that exposes the full DaVinci Resolve scripting API to AI assistants. This project was inspired by the davinci-resolve-mcp project by @samuelgursky, even though it is now a significantly different architecture.
Compatible with any AI system that supports modern MCP specifications.
Most MCP servers dump every available tool into the AI's context window at session start. With a large API surface, that means hundreds of tool definitions loaded whether or not the current task needs them — wasting tokens and slowing response time.
This server uses a kernel + domain architecture instead:
Kernel tools (always available, 6 total): activate_domain,
deactivate_domain, list_domains, get_version, get_current_page,
switch_page. These are useful regardless of what you're doing in Resolve.
Domain tools (loaded on demand): the full Resolve API is organized into
domains — Project Management, Timeline Operations, Media Pool, and more. Call
activate_domain("project_management") and the server fires a
notifications/tools/list_changed event; your MCP client refetches the tool
list and the domain's tools are immediately available, no session restart
needed.
Context cost at session start is bounded by the kernel alone. You expand it deliberately, only for the domains your current workflow actually needs.
Related MCP server: DaVinci Resolve MCP Server
This server is built for independent creators and boutique studios where AI API costs are real and context overhead matters.
Compared to other popular MCP servers for DaVinci Resolve:
Most alternatives load every available tool definition into the AI's context at session start. For a well-resourced production environment — a studio running Claude on dedicated infrastructure with token budgets absorbed into overhead — that approach is solid and the dense tool coverage is immediately useful.
This server makes a different architectural choice: 6 kernel tools at session start, domains activated on demand, context cost proportional to the work at hand. The full API surface (289 tools across 9 domains) is available, but none of it loads until you ask for it.
Typical MCP server |
| |
Tools at session start | All at once | 6 |
Total tools available | Fixed | 289 (9 domains) |
Domain activation | — | On demand |
If you're an independent creator or a small shop where every Claude API call has a cost, this architecture was designed for you. Professional-grade Resolve integration without professional-budget infrastructure requirements.
DaVinci Resolve Studio installed and licensed (the free edition does not support external scripting)
Python 3.10 or later, installed system-wide via the official installer with "Add to PATH" and "Install for all users" selected
Windows — critical: DaVinci Resolve locates Python through the Windows registry and loads
python3.dllby full path from that installation. A uv-managed or user-only Python install uses a different DLL and will cause a two-runtime crash at connection time. Always create the virtual environment from the system Python (see Installation below).
uv — fast Python package and virtual environment manager
git clone https://github.com/hoyt-harness/davinci-mcp-professional.git
cd davinci-mcp-professionalWindows — find your system Python path, then create the venv from it:
py -0p # lists installed Python versions and their pathsuv venv --python "C:\Program Files\Python314\python.exe" # adjust to your path
uv syncmacOS / Linux — uv venv with no --python flag works if the default
python3 is a system-wide installation:
uv venv
uv syncLocate or create claude_desktop_config.json:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
From source (Windows):
{
"mcpServers": {
"davinci-resolve": {
"name": "DaVinci MCP Professional",
"command": "C:\\path\\to\\davinci-mcp-professional\\.venv\\Scripts\\python.exe",
"args": ["C:\\path\\to\\davinci-mcp-professional\\mcp_server.py"]
}
}
}From source (macOS):
{
"mcpServers": {
"davinci-resolve": {
"name": "DaVinci MCP Professional",
"command": "/path/to/davinci-mcp-professional/.venv/bin/python",
"args": ["/path/to/davinci-mcp-professional/mcp_server.py"]
}
}
}Restart Claude Desktop after saving the config.
claude mcp add -s user davinci-resolve \
-- /path/to/davinci-mcp-professional/.venv/Scripts/python.exe \
/path/to/davinci-mcp-professional/mcp_server.pyThis writes to ~/.claude.json and makes the server available in all Claude
Code sessions without per-project configuration.
Start DaVinci Resolve and wait for it to fully load.
Start the MCP server (Claude Desktop / Claude Code does this automatically).
The server starts with 6 kernel tools available. Use list_domains to
see what domains are registered, then activate what you need:
What version of DaVinci Resolve is running? # get_version — no activation needed
List the available domains. # list_domains
Activate the project management domain. # activate_domain("project_management")
List all projects in the database. # list_projects — now available
Create a new timeline called "Act 1". # needs timeline_operations domain
Switch to the Color page. # switch_page — always in kernelDomain | Activates | Tools |
|
| Open/save/close/rename/delete projects, folder navigation, database switching |
|
| Tracks, markers, timecode, export/import, generators, Fusion clips |
|
| Folder management, clip operations, relink, mattes, stereo |
Any tool that permanently modifies or deletes data requires confirm: true in
its arguments. If you call a destructive tool without it, the server returns a
detailed error message describing exactly what would be destroyed and what you
need to set to proceed. This applies to operations like delete_project,
delete_timeline, delete_track, delete_media_pool_clips, and others.
Document | Purpose |
Developer setup, architecture, build instructions, contributing | |
Troubleshooting and bug reporting | |
Contribution guidelines | |
GPL-3.0 license |
Activate a domain to make its tools available. Available domains: ai_studio, clip_properties, color_grading, media_pool, project_management, render_delivery, system_fairlight_storage, timeline_item_editing, timeline_operations. Call list_domains to see current activation status.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name to activate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the primary effect—'make its tools available'—but does not explain side effects, idempotency, whether activating one domain deactivates another, persistence, or error behavior. This is a thin disclosure for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with action and purpose, followed by a list of valid domains and a pointer to list_domains. The domain list repeats the schema enum, but it serves as a convenient inline reference without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a single parameter and no output schema, so the description covers the basics: what to activate, the valid domains, and how to check status. However, it leaves the activation model under-specified—particularly whether domains are mutually exclusive or cumulative—and does not mention deactivate_domain as the reverse operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the domain parameter with an enum and 'Domain name to activate.' The description adds no meaningful semantics beyond listing the same enum values, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Activate a domain to make its tools available.' It lists all valid domain values, making the tool's scope explicit, and its purpose is clearly distinct from siblings like deactivate_domain and list_domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to 'Call list_domains to see current activation status,' directing the agent to the appropriate sibling for checking state. It does not explicitly contrast with deactivate_domain or describe when activation is unnecessary, but the core usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deactivate a domain to remove its tools from the active tool list.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name to deactivate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly reveals the primary side effect—removing tools from the active tool list—but does not mention reversibility, whether the domain itself is deleted, or any side effects for already-active tools. This is adequate but minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that leads with the action and object, then provides the meaningful consequence. Every word earns its place and there is no redundant restating of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter tool with no output schema, and the description explains what it does and what effect to expect. It is functionally sufficient for an agent to select and invoke the tool correctly, though it would be more complete if it explicitly confirmed that deactivation does not delete the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the meaning of 'domain' is already fully captured in the schema. The description adds no additional meaning beyond restating that the domain name is being deactivated, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Deactivate a domain' and clearly describes the intended outcome: 'remove its tools from the active tool list.' This differentiates it from sibling tools like list_domains, get_version, and switch_page, and makes activate_domain the obvious inverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when a domain's tools should no longer appear in the active tool list. It does not explicitly name alternatives or give when-not-to-use conditions, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current page open in DaVinci Resolve (Edit, Color, Fusion, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear the burden. It simply states 'Get', implying a read-only operation. No mention of side effects or edge cases (e.g., if no page is open). Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 11 words, front-loaded with verb and resource. No unnecessary information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters or output schema, the description provides sufficient context. It could mention the return format (e.g., a string) but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Description adds no extra parameter info, but this is acceptable for a parameterless tool. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and resource 'current page' with specific examples of pages (Edit, Color, Fusion). It distinguishes from sibling tools like 'switch_page'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The description implies its use for querying the current page, but does not mention alternatives like 'switch_page' or contexts where it might not be applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get DaVinci Resolve version information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose any behavioral traits such as side effects, authentication needs, or limitations. It simply restates the name, adding no extra insight beyond what the tool name provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is front-loaded and efficient, earning its place without any waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, but the description fails to mention the return format or any error conditions. Since there is no output schema, this information would be helpful. However, the description still provides the core purpose adequately, earning a mid-range score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% description coverage (trivially). The description does not need to elaborate on parameters, and the baseline score of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'DaVinci Resolve version information', making the tool's purpose immediately obvious. It effectively distinguishes itself from sibling tools which deal with projects, timelines, media, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or any context about prerequisites. While the tool is straightforward, the lack of any usage hints is a missed opportunity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered domains and their activation status. Use this to discover available domains before calling activate_domain.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, but 'List' clearly signals a non-mutating read operation and the description tells what is returned: all registered domains with their activation status. It does not cover pagination or exact output shape, but for a zero-parameter listing tool the core behavioral surface is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences: the first states the core function, the second gives practical usage guidance. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list operation with no output schema, the description provides the essential context: what is returned and when to invoke it. It could add detail on how activation status is represented, but nothing critical is missing for the agent to select and call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100%, so there is nothing missing to explain in the description. The rubric baseline for zero parameters applies, and no parameter-specific description is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List all registered domains and their activation status.' It clearly distinguishes itself from the sibling activation/deactivation tools by focusing on discovery and status rather than mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to discover available domains before calling activate_domain,' giving a specific when-to-use instruction and referencing a dependent sibling. This tells the agent exactly when this tool is the correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to a specific page in DaVinci Resolve
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | The page to switch to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without disclosing side effects (e.g., if already on the page), error conditions, or behavior beyond the basic switch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 10 words with no redundant information, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required enum parameter, no output schema), the description fully covers the necessary context for an agent to understand its purpose and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with enum descriptions. The description adds no extra meaning about the page parameter beyond what schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'switch' and resource 'page', and specifies the context 'in DaVinci Resolve'. It distinguishes from sibling tools like 'get_current_page' which reads the current page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'switch_timeline' or 'get_current_page'. No prerequisites or context of use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clear, distinct purpose: domain activation/lifecycle management versus version/page navigation. There is no overlap between list_domains, activate_domain, deactivate_domain, get_version, get_current_page, and switch_page. An agent should be able to consistently distinguish the appropriate tool.
The tools follow a consistent verb_noun pattern using snake_case: list_domains, activate_domain, deactivate_domain, get_version, get_current_page, switch_page. There are no mixing conventions or vague generic verbs, making the API predictable and self-documenting.
Six tools is within the acceptable range and the set is very lean, covering the apparent domain-management and page-navigation surface. However, given the reference to media_pool, project_management, and timeline_operations, the tool count feels slightly below what a professional DaVinci Resolve server would realistically expose.
The server lists domains like media_pool, project_management, and timeline_operations, but exposes no actual tools for those domains—no project creation, media import, timeline editing, or rendering operations. This is a severely incomplete surface for a DaVinci Resolve integration, leaving agents only able to manage domains and navigate pages.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hoyt-harness/davinci-mcp-professional'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
