davinci-mcp

Overview Schema Source Related Servers Discussions Admin

App (write)

app_write

Destructive

Change DaVinci Resolve application state—switch pages, manage presets, set keyframe mode or process priority—with read-back verification so changes that did not take are flagged.

Instructions

Change app state; may overwrite current values. Every change is read back from Resolve (receipt.verified=false means it did not take). op.action (params; * = required):

export_preset(kind*, name*, path*): Export a layout, keyboard, user-preferences or burn-in preset to a file.
import_preset(kind*, path*, name): Import a layout, keyboard, user-preferences or burn-in preset file.
load_preset(kind*, name*): Load a layout, keyboard or user-preferences preset.
open_page(page*): Switch Resolve to a page (media, cut, edit, fusion, color, fairlight, deliver).
save_preset(kind*, name*): Save the current layout or user preferences as a named preset.
set_high_priority(enabled*): Raise or restore the Resolve process priority (needs a real bool on 21.1).
set_keyframe_mode(mode*): Set the keyframe mode (all, color or sizing).
update_preset(kind*, name*): Overwrite a layout preset with the current window layout. Calls known in advance (a sequence, the same change on several items): ONE batch_run.

Input Schema

Name	Required	Description
`op`	Yes	{action, ...params}. Parameters per action: see the description or this server's describe_action tool.
`dry_run`	No	true: return the planned effect, change nothing.
`snapshot`	No	true: back up the timeline/project first; omitted: server policy.

Output Schema

Name	Required	Description	Default
`job`	No
`plan`	No
`status`	Yes
`receipt`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.0.4Nov 1, 2026
- addedInput schema / properties / dry_run / description
```
Added value: +"true: return the planned effect, change nothing."
```
- addedInput schema / properties / snapshot / description
```
Added value: +"true: back up the timeline/project first; omitted: server policy."
```
First observedv0.1.0Nov 1, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is known. The description adds real value beyond that: the read-back verification contract (receipt.verified=false means the change did not take) and the overwrite warning tell the agent how to detect failure and what risk it is taking, though it does not say exactly which state can be clobbered per action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two front-loaded sentences establish scope, risk and the verification contract, then a tight one-line-per-action list carries the detail. Every line is load-bearing; nothing repeats the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return shape need not be explained, and annotations cover safety. Given that, the description supplies everything else an agent needs: action inventory, per-action parameters, failure detection, and the batch_run escape hatch.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only enumerates action names inside a free-form nested object with additionalProperties; the description supplies the missing per-action contract, marking required vs optional parameters and giving accepted values (preset kinds, pages, keyframe modes). It converts a 100%-covered-but-uninformative schema into usable parameter semantics, well above the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Change app state') and then enumerates all eight concrete actions with one-line meanings, so an agent knows exactly what surface this tool covers. It also distinguishes itself from batch_run for multi-call sequences, separating it from the most likely sibling confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly routes batched/known-in-advance sequences to batch_run, which is a clear alternative-selection rule. However, it gives no guidance on when to prefer dry_run or snapshot, nor when to consult describe_action versus the inline parameter list, leaving some operational choices to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.