Use this before retrying `start_recording target="macos"` or
`start_app_window_recording` when macOS TCC may be blocking capture. The
response tells the client whether Screen Recording currently works, which
launcher process macOS is evaluating, where the user must grant permission,
and that the MCP client must be fully restarted after changing the setting.
Surface `user_message` directly when explaining the setup to the user.

This tool only checks Screen Recording. iOS Simulator and Android recordings
do not need Screen Recording. Pointer tools (`move_pointer` and
`hover_sequence`) need Accessibility permission instead.

Target aliases:
- macOS: "macos", "mac", or "desktop"
- iOS Simulator: "ios_simulator", "ios-simulator", "ios", or "simulator"
- Android: "android"

Common options include orientation and rotate_degrees. macOS options include
region, display, include_cursor, include_clicks, and include_audio. iOS
Simulator options include device, udid, and display ("internal" or
"external"). Android options include serial, size, and bit_rate.

Omit duration_seconds for the preferred manual-stop workflow, then call
stop_recording with the returned session_id. The response includes
session_id, video_path, target, mode, started_at, pid, and target_key.

macOS recording requires Screen Recording permission for the launcher
process. For browser or desktop-app debugging, prefer
start_app_window_recording so the visible app window is checked and only
that window region is recorded.

Call this after start_recording or start_app_window_recording returned a
session_id and the UI interaction has finished.

Always inspect file_exists and file_size_bytes before extracting frames:
file_exists must be true and file_size_bytes must be greater than zero.
Android sessions may also include pull_returncode from adb file transfer.

If stopping fails or the file is missing/empty, use list_active_sessions and
cleanup_stale_processes before retrying. Permission failures usually require
user action in macOS System Settings or on the Android device.

Use this when the client lost a session_id, duplicate-target protection is
blocking a new start_recording call, or before starting a fresh verification
run where old sessions would confuse results.

Pass target to filter by target family. Accepted values follow
start_recording aliases such as macos, ios_simulator, and android.
The response groups stopped session metadata under "stopped".

This does not discover recordings started by a dead prior server process;
use cleanup_stale_processes for that case. The response contains a
"sessions" list with session_id, target, target_key, video_path, mode,
started_at, duration_seconds, and pid for each active recording.

start_recording automatically runs this check before creating a new session,
so explicit calls are normally only needed after a stale-process error or
after an interrupted client run.

Cleanup is limited to processes owned by the current OS user. The response
reports any killed process/session records under "cleaned".

Requires macOS Accessibility permission for the launcher process. Use this
for single-point hover-only desktop checks when Computer Use drag would send
a mouse-up event and might activate the target.

For multiple hover/unhover points, prefer hover_sequence because it can
activate an app_name first and interpolate movement across segments.
The response echoes the final x and y coordinates.

This is the preferred hover fallback for canvas-style, WebGL, native, or
otherwise inaccessible pages where Playwright cannot target DOM elements.
It posts only mouse-move events and does not click.

Pass app_name to activate the target app immediately before the hover
sequence. steps_per_segment controls interpolation density and
step_delay_seconds controls the pause between generated points.

The response includes moved_count and final position fields from pointer
movement. When app_name is provided, active_window contains the visibility
check result used before moving.

Use this before macOS app or browser recording to verify the target window
is on screen, active, and sufficiently visible. The default
min_visible_ratio is 0.8; lower it only when partial visibility is
intentional.

The response includes visible, visible_ratio, region, frame, and screen
details. If visible is false, reposition or unminimize the window before
calling start_app_window_recording.

This is the first choice for Chrome, Safari, and desktop-app debugging. It
activates app_name, verifies the front window meets min_visible_ratio, then
records only that visible region via screencapture -R instead of recording
the full desktop.

Omit duration_seconds for the preferred manual-stop workflow, then call
stop_recording with the returned session_id. Options are forwarded to the
macOS backend after region is injected.

If visibility validation fails, the response is {"error": ..., "window": ...}
so the client can reposition or unminimize the target and retry.

mode="scene" selects frames around visual changes and uses scene_threshold
to control sensitivity; lower thresholds produce more frames. mode="fixed_fps"
samples at fps and should be used when timing matters more than scene
changes.

max_frames limits output size. When more frames are found than allowed, the
response reports dropped_for_max. inline_images=True returns FastMCP Image
content for clients that can display frames directly.

rotate_degrees applies orientation normalization when a backend produced a
sideways recording. ffmpeg and ffprobe must be available on PATH.

Use this when the recording length is known up front and no interactive
manual stop is needed. duration_seconds is required.

output_dir receives the captured recording file (recording.mov for macOS and
iOS Simulator, recording.mp4 for Android) and a frames/ directory containing
extracted images.

options are forwarded to start_recording. extract_options are forwarded to
extract_frames, including mode, scene_threshold, fps, max_frames,
inline_images, and rotate_degrees.