Scored across 52 tools
The domain-hub design (ai_read/ai_write/ai_delete, media_*, timeline_*, item_*, color_*, fusion_*, render_*, project_*) gives each tool a clearly distinct resource+intent, so an agent can pick a tool reliably. A few overlaps remain: batch_run vs recipe_run vs the workflow_write shortcuts all run multi-step sequences, and some ops are duplicated across hubs (get_audio_mapping in both media_read and audio_read, add_flag/clear_flags in both media_write and item_write, get_settings in project_read and timeline_read), which can cause misselection.
Nearly everything follows a noun_intent pattern (media_read, media_write, media_delete, job_status, recipe_list, snapshot_write), with the read/write/delete triad repeated consistently per domain. Standalone utilities break the pattern slightly (describe_action is verb_noun, vs resolve_status/batch_run/search_api which are noun_noun/noun_verb), but the deviations are few and still readable.
52 top-level tools is heavy for any agent to survey, even though each bundles many op.action sub-operations so the real surface is in the hundreds. The domain grouping softens the blow, but agents still need describe_action just to discover what a tool can do, and the scan cost plus duplicated hubs (media vs audio vs item) pushes this well past the comfortable 3-15 range.
The surface covers full lifecycle for every Resolve domain: media pool, timeline, items/takes/markers, color node graphs and versions, Fusion comps/tools/keyframes, audio, render job queue, project/database management, gallery, interchange formats, plus vision/screenshot, UI automation, jobs, snapshots and recipes. Read/write/delete triads exist everywhere and long-running work is handled with job_status/job_wait/job_cancel and pre-change snapshots, leaving no obvious dead ends.