davinci-resolve-mcp 2.99.2 → 2.99.3

package/CHANGELOG.md

@@ -2,6 +2,60 @@
 
 Release history for the DaVinci Resolve MCP Server. The latest release is summarized in the root README; older entries live here to keep the README focused.
 
+## What's New in v2.99.3
+
+**Fusion authoring now works on the free edition.** v2.99.2 documented that
+`fusion_comp add_tool` could not run there, because the in-app bridge reported
+`GetAttrs`/`SetAttrs` as absent on a Fusion tool and `add_tool` calls `GetAttrs`
+to build its return value — which took every server-authored Fusion graph with
+it. Investigating the fallback found the premise was wrong: **those methods are
+present and work.** Invoked directly on free 21.0.3.7, `GetAttrs` returned
+`{TOOLS_Name: "Blur1", TOOLS_RegID: "Blur"}` and `SetAttrs` renamed the tool.
+
+The fault was our capability check.
+
+### The API truth underneath
+
+`dir()` on a live Fusion Tool returns 38 names — with `Composition` listed
+**twice** — and omits `GetAttrs`/`SetAttrs`. Resolve fabricates a callable for
+*any* attribute name, so `dir()` is the only evidence of absence that exists,
+which makes an omitted name unrecoverable by probing. The bridge's strict proxy
+took that omission as authoritative and answered "has no attribute 'GetAttrs' in
+this Resolve build" for a method that was right there.
+
+Resolve's own API objects enumerate correctly — Timeline 60, TimelineItem 88,
+Composition 92 — so this is specific to Fusion Tools.
+
+### Fixed
+
+- The bridge client now carries a **curated exception**: names that are
+  documented Fusion methods but absent from the enumeration resolve normally,
+  and only on an object whose own method list positively identifies it as a
+  Fusion object (`ConnectInput`/`FindMainInput`/`GetControlPageNames` on a Tool,
+  `AddTool`/`FindTool`/`GetToolList` on a Composition).
+
+  This is deliberately not a global relaxation. Dropping the scoping fails five
+  existing tests, including the ones that keep
+  `getattr(item, "CreateMagicMask", None)` honest — capability detection on
+  Resolve API objects answers exactly as before.
+
+- `fusion_comp add_tool` needed **no change**. The fallback proposed in v2.99.2
+  would have papered over a client bug while leaving every other unenumerated
+  Fusion method broken.
+
+### Live validation
+
+Free DaVinci Resolve 21.0.3.7, whole graph through the server including a custom
+tool name (which requires `SetAttrs`):
+
+```
+add_tool   -> {'tool_name': 'FreeBlur', 'tool_type': 'Blur'}
+connect    -> {'success': True}
+connect    -> {'success': True}
+set_input  -> {'success': True}
+render     -> PSNR 23.32 dB vs baseline — RENDERED
+```
+
 ## What's New in v2.99.2
 
 **The Fusion comp-lock question is closed on Resolve 21.** The v2.98.5–v2.98.8

package/README.md

@@ -2,7 +2,7 @@
 
 English | [简体中文](README.zh-CN.md)
 
-[![Version](https://img.shields.io/badge/version-2.99.2-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-2.99.3-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
 [![npm](https://img.shields.io/npm/v/davinci-resolve-mcp.svg?label=npm&color=CB3837)](https://www.npmjs.com/package/davinci-resolve-mcp)
 [![API Coverage](https://img.shields.io/badge/API%20Coverage-100%25-brightgreen.svg)](docs/reference/api-coverage.md)
 [![Tools](https://img.shields.io/badge/MCP%20Tools-35%20(353%20full)-blue.svg)](#server-modes)

package/README.zh-CN.md

@@ -2,7 +2,7 @@
 
 [English](README.md) | 简体中文
 
-[![Version](https://img.shields.io/badge/version-2.99.2-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-2.99.3-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
 [![npm](https://img.shields.io/npm/v/davinci-resolve-mcp.svg?label=npm&color=CB3837)](https://www.npmjs.com/package/davinci-resolve-mcp)
 [![API Coverage](https://img.shields.io/badge/API%20Coverage-100%25-brightgreen.svg)](docs/reference/api-coverage.md)
 [![Tools](https://img.shields.io/badge/MCP%20Tools-35%20(353%20full)-blue.svg)](#服务器模式)
@@ -12,7 +12,7 @@
 [![Python](https://img.shields.io/badge/python-3.10+-green.svg)](https://www.python.org/downloads/)
 [![License](https://img.shields.io/badge/license-MIT-blue.svg)](https://opensource.org/licenses/MIT)
 
-> 本翻译对应 v2.99.2 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
+> 本翻译对应 v2.99.3 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
 
 一个 Model Context Protocol (MCP) 服务器，让 AI 助手通过官方脚本 API 控制 DaVinci Resolve Studio（达芬奇）。它提供完整的 API 覆盖，外加带护栏的工作流助手，涵盖剪辑、媒体池整理、渲染设置、审阅标记、调色、Fusion、Fairlight、项目生命周期任务、扩展开发，以及不碰源媒体的媒体分析。
 

package/docs/reference/api-limitations.md

@@ -355,13 +355,13 @@ values, or automation-hostile modal prompts.
 - **Workaround / current handling:** Author OTIO for Resolve by mirroring what Resolve itself exports, and give every event its media timecode origin. editorial.convert_to_interchange (target 'otio') does this and reports any event whose origin had to be assumed in `mediaOriginAssumed` — a non-empty list means the file will only import if that media really starts at 00:00:00:00. To debug a refusal, export any timeline with EXPORT_OTIO and diff your document against it; do NOT chase missing media or reach for sanitize_media, which cannot even parse a .otio (it is JSON, not XML).
 - **Tags:** timeline, import, interchange, otio, silent-failure, conform
 
-### Fusion tool GetAttrs / SetAttrs (unreachable over the in-app bridge)
+### Fusion object dir() omits real methods (GetAttrs / SetAttrs)
 
-- **Object:** `Fusion Tool (via the free-edition bridge)`
-- **Signature:** `GetAttrs() -> dict / SetAttrs(dict) -> None`
-- **Behavior:** The in-app bridge's transparent proxy exposes SetInput, GetInput, ConnectInput and FindMainInput on a Fusion tool, but NOT GetAttrs or SetAttrs - the client raises AttributeError('... has no attribute SetAttrs in this Resolve build'). Measured 2026-08-22 on free 21.0.3.7. Because fusion_comp's add_tool calls tool.GetAttrs() unconditionally to build its return value, and SetAttrs whenever a name is passed, `fusion_comp add_tool` cannot run at all on the free edition, which takes connect/set_input with it for any graph the caller wanted to build through the server. Comp-level calls (AddFusionComp, GetFusionCompByIndex, FindTool, AddTool) work, so the graph can still be wired with raw proxy calls.
-- **Workaround / current handling:** On the free edition, wire Fusion graphs with raw comp.AddTool/ConnectInput and use fusion_comp only for value writes. Making add_tool tolerate a missing GetAttrs (fall back to the requested tool_type and a FindTool-based name) would restore the action there.
-- **Tags:** fusion, bridge, free-edition
+- **Object:** `Fusion Tool / Composition`
+- **Signature:** `dir(tool) -> incomplete list`
+- **Behavior:** `dir()` on a live Fusion Tool returns 38 names — with 'Composition' listed TWICE — and omits GetAttrs and SetAttrs, which are documented Fusion Tool methods that work perfectly when called. Measured on free 21.0.3.7 over the in-app bridge: invoking GetAttrs directly returned {TOOLS_Name: 'Blur1', TOOLS_RegID: 'Blur'} and SetAttrs renamed the tool. This matters because Resolve fabricates a callable for ANY attribute name, so `dir()` is the only evidence of absence that exists — which makes an omitted name unrecoverable by probing. Any capability detection built on dir()/hasattr will therefore report a real Fusion method as missing. Resolve's own API objects do not have this problem: Timeline (60), TimelineItem (88) and Composition (92) all enumerate correctly.
+- **Workaround / current handling:** Do not treat dir()/hasattr as authoritative for Fusion Tool objects. Keep a curated set of documented Fusion methods that the enumeration omits, and identify a Fusion object positively (ConnectInput / FindMainInput / GetControlPageNames on a Tool, AddTool / FindTool / GetToolList on a Composition) rather than relaxing the check globally, which would silently re-open capability detection on Resolve API objects.
+- **Tags:** fusion, introspection, bridge, free-edition
 
 ### Composition.Lock (suppresses render invalidation for value writes)
 

package/install.py

@@ -37,7 +37,7 @@ from src.utils.update_check import (
 
 # ─── Version ──────────────────────────────────────────────────────────────────
 
-VERSION = "2.99.2"
+VERSION = "2.99.3"
 # Only hard floor: mcp[cli] requires Python 3.10+. There is no upper bound —
 # Resolve's scripting bridge loads into newer interpreters on recent builds
 # (Python 3.14 verified against Resolve Studio 20.3.2). Older Resolve builds

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "davinci-resolve-mcp",
-  "version": "2.99.2",
+  "version": "2.99.3",
   "description": "NPM bootstrapper for the DaVinci Resolve MCP Server.",
   "license": "MIT",
   "author": "Samuel Gursky <samgursky@gmail.com>",

package/src/granular/common.py

@@ -87,7 +87,7 @@ if not logging.getLogger().handlers:
         handlers=[logging.StreamHandler()],
     )
 
-VERSION = "2.99.2"
+VERSION = "2.99.3"
 logger = logging.getLogger("davinci-resolve-mcp")
 logger.info(f"Starting DaVinci Resolve MCP Server v{VERSION}")
 logger.info(f"Detected platform: {get_platform()}")

package/src/server.py

@@ -11,7 +11,7 @@ Usage:
     python src/server.py --full       # Start the 353-tool granular server instead
 """
 
-VERSION = "2.99.2"
+VERSION = "2.99.3"
 
 import base64
 import os

package/src/utils/api_truth.py

@@ -404,29 +404,34 @@ API_TRUTH: List[Dict[str, Any]] = [
         "submit": "bug",
     },
     {
-        "symbol": "Fusion tool GetAttrs / SetAttrs (unreachable over the in-app bridge)",
-        "object": "Fusion Tool (via the free-edition bridge)",
-        "signature": "GetAttrs() -> dict / SetAttrs(dict) -> None",
-        "reality": "The in-app bridge's transparent proxy exposes SetInput, "
-                   "GetInput, ConnectInput and FindMainInput on a Fusion tool, "
-                   "but NOT GetAttrs or SetAttrs - the client raises "
-                   "AttributeError('... has no attribute SetAttrs in this "
-                   "Resolve build'). Measured 2026-08-22 on free 21.0.3.7. "
-                   "Because fusion_comp's add_tool calls tool.GetAttrs() "
-                   "unconditionally to build its return value, and SetAttrs "
-                   "whenever a name is passed, `fusion_comp add_tool` cannot "
-                   "run at all on the free edition, which takes "
-                   "connect/set_input with it for any graph the caller wanted "
-                   "to build through the server. Comp-level calls "
-                   "(AddFusionComp, GetFusionCompByIndex, FindTool, AddTool) "
-                   "work, so the graph can still be wired with raw proxy calls.",
-        "recommended": "On the free edition, wire Fusion graphs with raw "
-                       "comp.AddTool/ConnectInput and use fusion_comp only for "
-                       "value writes. Making add_tool tolerate a missing "
-                       "GetAttrs (fall back to the requested tool_type and a "
-                       "FindTool-based name) would restore the action there.",
-        "tags": ["fusion", "bridge", "free-edition"],
+        "symbol": "Fusion object dir() omits real methods (GetAttrs / SetAttrs)",
+        "object": "Fusion Tool / Composition",
+        "signature": "dir(tool) -> incomplete list",
+        "reality": "`dir()` on a live Fusion Tool returns 38 names — with "
+                   "'Composition' listed TWICE — and omits GetAttrs and "
+                   "SetAttrs, which are documented Fusion Tool methods that "
+                   "work perfectly when called. Measured on free 21.0.3.7 over "
+                   "the in-app bridge: invoking GetAttrs directly returned "
+                   "{TOOLS_Name: 'Blur1', TOOLS_RegID: 'Blur'} and SetAttrs "
+                   "renamed the tool. This matters because Resolve fabricates a "
+                   "callable for ANY attribute name, so `dir()` is the only "
+                   "evidence of absence that exists — which makes an omitted "
+                   "name unrecoverable by probing. Any capability detection "
+                   "built on dir()/hasattr will therefore report a real Fusion "
+                   "method as missing. Resolve's own API objects do not have "
+                   "this problem: Timeline (60), TimelineItem (88) and "
+                   "Composition (92) all enumerate correctly.",
+        "recommended": "Do not treat dir()/hasattr as authoritative for Fusion "
+                       "Tool objects. Keep a curated set of documented Fusion "
+                       "methods that the enumeration omits, and identify a "
+                       "Fusion object positively (ConnectInput / FindMainInput "
+                       "/ GetControlPageNames on a Tool, AddTool / FindTool / "
+                       "GetToolList on a Composition) rather than relaxing the "
+                       "check globally, which would silently re-open capability "
+                       "detection on Resolve API objects.",
+        "tags": ["fusion", "introspection", "bridge", "free-edition"],
         "submit": "bug",
+        "mitigation": ["_FUSION_UNENUMERATED_METHODS", "_FUSION_OBJECT_MARKERS"],
     },
     {
         "symbol": "Composition.Lock (suppresses render invalidation for value writes)",

package/src/utils/resolve_bridge_client.py

@@ -198,6 +198,34 @@ def _decode_value(transport: BridgeTransport, value: Any) -> Any:
     return value
 
 
+# Fusion's own objects under-report themselves, and unlike Resolve's they cannot
+# be probed. `dir()` on a Fusion Tool lists 38 names — with "Composition"
+# appearing twice — and omits GetAttrs/SetAttrs, which are documented Fusion Tool
+# methods that work perfectly when called: measured on free 21.0.3.7 over this
+# bridge, GetAttrs returned {TOOLS_Name: "Blur1", TOOLS_RegID: "Blur"} and
+# SetAttrs renamed the tool. Resolve fabricates a callable for ANY name, so
+# `dir()` is the only evidence of absence that exists — which means a name it
+# omits cannot be recovered by probing, only by knowing.
+#
+# This is a curated exception, not a relaxation of the strict proxy. It applies
+# only to names that are documented Fusion methods, and only on an object whose
+# own method list identifies it as a Fusion object. Resolve API capability
+# detection — `getattr(item, "CreateMagicMask", None)` — answers exactly as
+# before, which is what the strict proxy exists to protect.
+#
+# Symptom when this is missing: `fusion_comp add_tool` calls tool.GetAttrs() to
+# build its return value, so the action died with "has no attribute 'GetAttrs'
+# in this Resolve build" and took every server-authored Fusion graph with it.
+_FUSION_UNENUMERATED_METHODS = frozenset({"GetAttrs", "SetAttrs"})
+
+#: Names that positively identify a Fusion Tool or Composition, as opposed to a
+#: Resolve API object. Drawn from what `dir()` DOES report on each.
+_FUSION_OBJECT_MARKERS = frozenset({
+    "ConnectInput", "FindMainInput", "GetControlPageNames",   # Tool
+    "AddTool", "FindTool", "GetToolList",                     # Composition
+})
+
+
 class _BoundMethod:
     """One callable method on a proxied object."""
 
@@ -309,6 +337,11 @@ class BridgeProxy:
                                                 {"target": self._handle, "name": name}) or {}
                 if probe.get("kind") == "value":
                     return _decode_value(self._transport, probe.get("value"))
+                if (name in _FUSION_UNENUMERATED_METHODS
+                        and self._methods() & _FUSION_OBJECT_MARKERS):
+                    # A Fusion object omitting one of its own documented
+                    # methods — see _FUSION_UNENUMERATED_METHODS.
+                    return _BoundMethod(self._transport, self._handle, name)
                 # Matches native semantics: hasattr() is False, getattr(..., None)
                 # is None, and a capability check refuses instead of guessing.
                 # A `callable` answer lands here too — Resolve fabricates one for