Several read-only inspection tools overlap: scan_environment already inventories game, camera, PP filter and recorder data that list_camera_tools, list_camera_presets and list_pp_filters each report separately, and probe_replay_bridge vs get_live_replay_status both concern replay status. Descriptions are unusually explicit about boundaries (e.g. 'not a runtime active-filter check'), which rescues most of the ambiguity, but an agent still faces a real choice between aggregate and per-item listing tools.

Every tool is snake_case verb_noun with a clear verb from a small family (list_, validate_, get_, probe_, scan_, create_, prepare_, set_, activate_, capture_, restore_). The pattern is predictable and readable across all 15 tools, with no camelCase or noun-only outliers.

15 tools is at the top of the reasonable band, and four of them (activate_camera, set_pp_filter, capture_replay_shot, restore_original_configuration) are explicit no-op placeholders that perform no action. They arguably serve as safety documentation, but functionally the surface is ~11 read-only tools plus four stubs, which feels padded for the delivered capability.

The stated domain is cinematic direction — plan, launch, camera control, filter selection, shot capture — but every mutating operation in that lifecycle is a safety-gated placeholder that does nothing. The server only covers the read-only validation/inventory half of the workflow, so an agent cannot complete any cinematic task end to end.