Skip to main content
Glama
Aedelon

davinci-mcp

by Aedelon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Project (write)

project_write
Destructive

Manage DaVinci Resolve project state: create, load, save, rename, export, archive, and configure projects/settings, with every write verified by read-back.

Instructions

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

  • apply_settings_preset(name*): Apply a settings preset to the current project (saved project only).

  • archive_project(name*, path*, with_stills_and_luts, archive_src_media, archive_render_cache, archive_proxy_media, force): Archive a project (broken by script on 21.x; needs force=true).

  • close_project(save_first, discard_untitled): Close the current project (saved first by default).

  • create_folder(name*): Create a project folder in the current database folder.

  • create_project(name*, media_location_path, discard_untitled): Create a project and make it current (saves the current one first).

  • export_project(name*, path*, with_stills_and_luts): Export a project of the current folder to a .drp file.

  • export_settings_preset(name*, path*): Export a project settings preset to a file.

  • goto_folder(to*): Go to the root or the parent project folder.

  • import_project(path*, name): Import a .drp project file into the current folder.

  • import_settings_preset(path*, name): Import a project settings preset file.

  • load_project(name*, discard_untitled): Load a project from the current folder (saves the current one first).

  • open_folder(name*): Enter a sub-folder of the current project folder.

  • rename_project(new_name*): Rename the current project.

  • restore_project(path*, name): Restore a project from an archive (.dra folder) into the current folder.

  • save_project(): Save the current project (refused for 'Untitled Project').

  • save_settings_preset(name*): Save the current project settings as a new preset.

  • set_database(database*, discard_untitled): Switch the current database (DbType, DbName, optional IpAddress).

  • set_settings(settings*): Set project settings one key at a time, verified by read-back.

  • update_settings_preset(name*): Overwrite a settings preset with the current project settings. Calls known in advance (a sequence, the same change on several items): ONE batch_run.

Input Schema

NameRequiredDescriptionDefault
opYes{action, ...params}. Parameters per action: see the description or this server's describe_action tool.
dry_runNotrue: return the planned effect, change nothing.
snapshotNotrue: back up the timeline/project first; omitted: server policy.

Output Schema

NameRequiredDescriptionDefault
jobNo
planNo
statusYes
receiptNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.4
    • 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."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the destructiveHint=true annotation, it discloses that changes are read back from Resolve and that receipt.verified=false means the write did not take — a critical behavioral contract. It also surfaces implicit side effects annotations cannot express: current project is saved first, untitled projects are discarded, presets are overwritten.

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

Conciseness3/5

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

Front-loaded with the key behavioral warning and the batch_run redirect, and the bulleted action list is scannable — but this is a long wall of text where 19 lines at uniform granularity force the agent to read past many irrelevant actions to find its one. Structure is functional, not lean.

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

Completeness4/5

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

Rich coverage: dry_run/snapshot are schema-described, the return contract (read-back verification, receipt.verified) is explained despite an output schema existing, and per-action prerequisites are stated. Missing only that set_database's database param shape (DbType/DbName/IpAddress) is named but not typed.

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

Parameters4/5

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

The schema only declares action as an enum with additionalProperties=true, so the description carries the real parameter burden by listing required (*) and optional params for each action — substantial value beyond the schema. The '*' convention is inferable but never stated explicitly, and types for nested params are not given.

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?

Opens with a specific verb+resource+scope ('Change project state; may overwrite current values') and then enumerates all 19 actions with per-action effects, so the agent knows exactly what class of mutation lives here versus project_read/project_delete. The alternative-route note for batch sequences further sharpens the boundary.

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?

Explicitly routes known-in-advance repeated changes to batch_run, and embeds situational qualifiers per action ('saved project only', 'needs force=true' on 21.x, 'refused for Untitled Project'). It stops short of stating general when-not-to-use conditions (e.g., preferring dry_run for exploratory changes), which keeps it off a 5.

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

Deploy Server

Other Tools