Author and install Resolve-page Lua/Python scripts (Workspace → Scripts menu). Scripts live under the per-category subdirs of Resolve's Fusion/Scripts/ directory and appear automatically in Workspace → Scripts → <category> on the page that matches the category. Resolve picks up new scripts withou...
AI agents invoke script_plugin to trigger actions in DaVinci Resolve MCP. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call — builds kicked off, notifications sent, workflows started.
This tool writes and installs arbitrary Lua or Python scripts into DaVinci Resolve's scripts directory, which are then automatically executed when triggered from the menu. Authoring and installing executable code that runs in the context of a live application is Execute-category behavior.
From the tool's definition Author and install Resolve-page Lua/Python scripts
Documented attack patterns abuse exactly the kind of access script_plugin 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 script_plugin:
{
"version": "1",
"default": "deny",
"tools": {
"script_plugin": {
"limits": [
{
"counter": "script_plugin_rate",
"window": "minute",
"max": 10,
"scope": "grant"
}
]
}
}
}script_plugin stays usable, but rate-capped — a runaway agent can't fire it dozens of times a minute. Everything else on the server is denied unless you say otherwise.
Free to start. No card required.
Author and install Resolve-page Lua/Python scripts (Workspace → Scripts menu). Scripts live under the per-category subdirs of Resolve's Fusion/Scripts/ directory and appear automatically in Workspace → Scripts → <category> on the page that matches the category. Resolve picks up new scripts without a restart — the menu refreshes the next time it's opened. Categories: 'Edit', 'Color', 'Deliver', 'Comp', 'Tool', 'Utility', 'Views'. 'Utility' shows up everywhere; the rest only on the matching page. Two template kinds: - 'scaffold' minimal stub with Resolve handle setup - 'media_rules' rules-and-variables DSL (declarative VARIABLES + RULES interpreted by an embedded engine; supports sources, extract patterns, transforms, targets, actions, conditions, dry-run, external CSV/JSON data, fuzzy matching, and per-rule metadata) Both languages (Lua and Python) generate fully self-contained scripts. See docs/authoring/script-plugin-authoring.md for the DSL spec. Actions: path(category) -> {scripts_dir} categories() -> {categories} list(category?, all?, language?) -> {scripts} install(name, source, category, language?, overwrite?) -> {success, path} remove(name, category, language) -> {success} read(name, category, language) -> {source} validate(source, language?) -> {valid, errors, checker} template(kind, name, options?) -> {source, kind, name, language} — kind: 'scaffold' | 'media_rules' — options: {language: 'lua'|'py', ...kind-specific} list_templates() -> {kinds} execute(name, category, language, args?, timeout?) -> {success, stdout?, stderr?, exit_code?} — Python: subprocess with stdout/stderr captured. — Lua: fusion.RunScript(); print() output goes to Resolve Console. — args: list of CLI args for the Python subprocess (Python only). — timeout: seconds (default 120 for execute, 60 for run_inline). — Auto-launches Resolve if not running. run_inline(source, language, timeout?) -> {success, stdout?, stderr?, result?} — Python: writes to temp file with resolve/project/mp/timeline pre-bound, runs as subprocess, captures stdout/stderr. — Lua: fusion.Execute(source); return value comes back as result. — Use this for ad-hoc one-shot queries without persisting a file. extension_capabilities() -> {paths, templates, lifecycle, safe_guards} probe_fuse_lifecycle(name?, kind?, install?, cleanup?) -> {template, validation, install?, remove?} probe_dctl_lifecycle(name?, kind?, category?, install?, refresh_luts?, cleanup?) -> {template, validation, install?, remove?} probe_script_lifecycle(name?, language?, category?, install?, execute?, cleanup?) -> {template, validation, install?, execute?, remove?} safe_install_extension(extension_type, name, source?|kind?, dry_run?) -> {success} safe_remove_extension(extension_type, name, dry_run?) -> {success} refresh_or_restart_required(extension_type, category?) -> {refresh_luts, restart_required} extension_boundary_report(include_template_matrix?) -> {capabilities, template_matrix, dry_run_probes}. It is categorised as a Execute tool in the DaVinci Resolve MCP MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
Register the DaVinci Resolve MCP server in PolicyLayer and add a rule for script_plugin: 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.
script_plugin is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the script_plugin 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 script_plugin. 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.
script_plugin 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.