Start a Resolve Session

Run this at the top of an editing conversation so the session begins with known state instead of four rounds of discovery. Report findings compactly; this is orientation, not an audit.

Steps

1. Connect and identify the host.

   resolve_control(action="get_version"), or the nearest capability action.

   Capture: Resolve version, Studio vs free edition, and whether this connected over external scripting or the in-app bridge. If the connection fails, read the error's own remediation field and follow it, it names the applicable fix. A connection error does not mean the free edition is unsupported; the bridge path (Workspace > Scripts > resolve_bridge) covers it, and is used automatically once running, DAVINCI_RESOLVE_BRIDGE=1 only forces it.

   Report both versions: version_string is the Resolve build, mcp.version is this server. They fail differently, and one of them is easy to forget, a running MCP keeps executing the version it started with, so a git pull does not refresh its ledger until restart.

2. Ask what this build cannot do.

   get_version already answers this in its build.unavailable_on_this_build block, so read that first; resolve_control(action="check_version_support") is for asking about one named symbol, or for re-checking after a reconnect.

   The scripting API changes per patch release, so "Resolve 21" is not a usable label: GetFairlightPresets needs 20.2.2, and three surfaces exist in 21.0.4 but not 21.0.2. Knowing this at the top of the session is the difference between "that needs 21.0.4, here is the alternative" and discovering it halfway through a task.

   Two things to hold on to: