Manage DaVinci Resolve projects. Actions: list() -> {projects} get_current() -> {name, id} create(name, media_location_path?) -> {success, name} load(name) -> {success} save() -> {success} close() -> {success} delete(name) -> {success} import_project(path, name?) -> {success} export_project(name,...
AI agents call project_manager to permanently remove resources in DaVinci Resolve MCP — typically in cleanup and lifecycle workflows. It does its job in a single call, and there is no undo.
While the tool also performs read and write operations (list, create, load, save), the presence of delete() elevates this to Destructive category per the severity hierarchy. A delete action on a DaVinci Resolve project cannot be undone and results in permanent loss of editing work, timelines, and project metadata. An AI agent given unrestricted access could irreversibly destroy projects.
From the tool's definition Tool includes delete(name) which "irreversibly deletes" projects, and archive/restore operations that can overwrite or permanently remove project data. The export and import functions also manipulate project files with potential data loss.
Documented attack patterns abuse exactly the kind of access project_manager gives an agent:
PolicyLayer is an MCP gateway — it sits between your AI agents and DaVinci Resolve MCP, and nothing reaches the server without passing your rules. This is the rule we recommend for project_manager:
{
"version": "1",
"default": "deny",
"hide": [
"project_manager"
]
}project_manager disappears from the agent's tool list entirely, and any attempt to call it is denied. The rest of the server keeps working.
Free to start. No card required.
Manage DaVinci Resolve projects. Actions: list() -> {projects} get_current() -> {name, id} create(name, media_location_path?) -> {success, name} load(name) -> {success} save() -> {success} close() -> {success} delete(name) -> {success} import_project(path, name?) -> {success} export_project(name, path, with_stills_and_luts?) -> {success} archive(name, path, src_media?, render_cache?, proxy_media?) -> {success} restore(path, name?) -> {success} project_capabilities() -> {capabilities} probe_project_lifecycle() -> {project_manager, ...} probe_project_settings(keys?, try_write?) -> {snapshot, candidate_settings} safe_project_create(name, media_location_path?, dry_run?) -> {success} safe_project_export(name, path, with_stills_and_luts?, dry_run?) -> {success} safe_project_import(path, name, dry_run?) -> {success} safe_project_archive(name, path, src_media=false, render_cache=false, proxy_media=false, dry_run?) -> {success} safe_project_restore(path, name, dry_run?) -> {success} safe_project_delete(name, close_current?, dry_run?) -> {success} safe_set_project_settings(settings, restore?, dry_run?) -> {success} project_settings_snapshot(name?) -> {project, settings, presets, ...} database_capabilities() -> {methods, current, databases} safe_set_current_database(db_info, dry_run?, allow_switch?) -> {success} preset_lifecycle_probe() -> {project_presets, render_presets, layout_presets, ...} project_boundary_report() -> {capabilities, project_manager, settings, database, presets, cloud} lint() -> {ok, counts, issues} — graded project health pre-flight (no project, no current timeline, mixed fps, empty timeline, render/color-science unset, offline media). diff_to_spec(spec_path|spec) -> {actions, diff, change_count} — preview drift vs a declarative spec WITHOUT mutating. Spec is YAML/JSON: {project, color_preset?, settings?, timelines:[{name,fps?,settings?,markers?}], hooks?}. plan_spec(spec_path|spec) -> {dry_run, actions, diff, change_count} — same as apply with dry_run. apply_spec(spec_path|spec, dry_run?, run_hooks?, continue_on_error?) -> {success, applied, failures} Reconcile the project toward the spec (idempotent: re-runs are no-ops). Color/HDR settings are applied in dependency order; markers only added if absent. Hooks run only when run_hooks=true (executes shell from the spec — opt-in). It is categorised as a Destructive tool in the DaVinci Resolve MCP MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.
Register the DaVinci Resolve MCP server in PolicyLayer and add a rule for project_manager: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches DaVinci Resolve MCP. Nothing to install.
project_manager is a Destructive tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.
Yes. Add a rate_limit block to the project_manager rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for project_manager. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
project_manager is provided by the DaVinci Resolve MCP server (samuelgursky/davinci-resolve-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 369 DaVinci Resolve MCP tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
369 DaVinci Resolve MCP tools catalogued and risk-classified — across an index of 42,500+ MCP servers.