Nvidia Broadcast

NVIDIA Broadcast

Hard rules

1. Launching: start Broadcast only by running powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<skill_dir>\scripts\launch_broadcast.ps1" with the terminal tool. When running inside WSL, follow Launch and version-check through interop in references/connection.md instead. Except for the security-policy fallback below and that WSL interop procedure, never invoke NVIDIA Broadcast.exe directly — not via terminal, execute_code, subprocess, or Start-Process.

   Security-policy fallback: use this only if security policy blocks the launcher script. Confirm that NVIDIA Broadcast.exe is not already running, then run: powershell.exe -NoProfile -Command "Start-Process -FilePath ([Environment]::ExpandEnvironmentVariables('%ProgramFiles%\NVIDIA Corporation\NVIDIA Broadcast\NVIDIA Broadcast.exe')) -ArgumentList '--launch-hidden' -WindowStyle Hidden" with the terminal tool.

2. Command tools: follow Which tool to run commands with below.

3. Never read effect state from disk — not AppSetting.json, not the registry, not logs, not the UI. Those are saved settings, not live state. Exception: gateway.json may be read and decoded only to obtain the gateway port for rule 4; it is connection configuration, not effect state.

4. Connecting to the gateway — exactly these steps, no other path:

   1. Before launching or registering the gateway, check the standard executable path and read its ProductVersion without launching it. If the executable is missing or its version is 2.2.x or older, stop the connection sequence and follow Installing or updating NVIDIA Broadcast. Do not return the restart-only response below.

   2. Check Broadcast is running: tasklist /FI "IMAGENAME eq NVIDIA Broadcast.exe" via terminal. If Broadcast is installed but not running, launch it immediately (rule 1); do not ask the user to start it manually. A gateway.json left from an earlier run proves nothing about whether the gateway is live.

   3. Whether already running or just launched, retry for up to 60 seconds: reread and base64-decode %APPDATA%\nvidia-broadcast\gateway.json → {"port": <number>}. Use the port from the latest successful read. Decode gateway.json within the command and output only the port. Never print its base64 contents because credential redaction may mask them.

   4. Register http://127.0.0.1:<port>/gateway with your MCP client as a Streamable HTTP server. You are the MCP client — register it yourself.

   5. Verify the server reports its name as nvidia-broadcast via the MCP client's server info. If it does not, treat NVIDIA Broadcast as unavailable, use the restart response below, and stop.

   6. Check whether the NVIDIA Broadcast MCP tools required for the user's request are available.

   If the required tools are available, the connection is ready; proceed with the requested operation.

   Stop if any of these occurs — report and go no further:

   • Registration fails, or

   • the server name is not nvidia-broadcast, or

   • after registering, any required NVIDIA Broadcast MCP tool is not in your tool list.

   Reply only: "NVIDIA Broadcast MCP tools are unavailable in this session. Please restart your MCP client and retry." Then stop. Do not add rationale, gateway URLs, port details, configuration instructions, or post-restart steps. Do not substitute another source or guess which effects are on.

5. Only after completing rule 4, if any required NVIDIA Broadcast MCP tool is still not in your tool list, that is the final answer. Stop. Its initial absence is not a reason to skip launch or registration. Do not try to make it work. Specifically, never:

   • Write, generate, or run any code that speaks MCP or HTTP to the gateway — urllib, http.client, socket, requests, httpx, curl, Invoke-WebRequest, or anything else. A correct, spec-compliant client is still a violation. The prohibition is on you speaking the protocol at all, not on which library you choose.

   • Search for, install, or run an MCP client binary — which mcp, mcp exec, npx @modelcontextprotocol/cli, pip install mcp[cli].

   • Scan ports, hunt the filesystem for an endpoint, or delegate to another agent or session. Use exactly the restart response from rule 4, then stop. A state read obtained by any other route is not a valid substitute, and a guessed effect list is simply wrong.

6. Recover from MCP connection failures. If any NVIDIA Broadcast tool call fails because the MCP connection was closed, refused, reset, disconnected, or otherwise became unavailable, repeat the connection sequence in rule 4:

   1. Check whether NVIDIA Broadcast.exe is running.

   2. If it is not running, launch it using rule 1. If it is already running, do not launch another instance.

   3. Reread gateway.json, obtain the current port, and register the gateway again.

   4. Verify the server reports its name as nvidia-broadcast. If it does not, use the short restart response from rule 4 and stop.

   5. Check whether the NVIDIA Broadcast MCP tools required for the user's request are available.

   If the tools are still unavailable, use the short restart response from rule 4 and stop. After reconnecting, retry a read-only or idempotent tool call at most once. Do not automatically repeat a non-idempotent request when the connection closed after submission because it may already have been accepted.

   Do not run this recovery sequence for normal gateway or tool errors such as invalid arguments, ambiguous_frame_rate, device_not_selected, file_not_found, rate limiting, or an effect operation failure.

Purpose

NVIDIA Broadcast applies AI effects to your camera, microphone, and speaker, and can apply the same effects to local media files. You drive it over a local MCP gateway that NVIDIA Broadcast runs on loopback. It also lets you check and change AI effects, select Studio Voice microphone profiles, manage camera, microphone, and speaker devices, and change camera resolution.

Prerequisites

• Windows host with NVIDIA Broadcast installed. 2.2.x and older have no MCP gateway and cannot be driven by this skill at all. When it is missing or too old, you may offer to install it from NVIDIA's update service — see Installing or updating NVIDIA Broadcast below. Never install without asking.

• Standard executable path: %ProgramFiles%\NVIDIA Corporation\NVIDIA Broadcast\NVIDIA Broadcast.exe.

• MCP gateway config readable at %APPDATA%\nvidia-broadcast\gateway.json.

• The current agent runtime acts as the MCP client and connects through Streamable HTTP over loopback.

• Running inside WSL: the gateway lives on the Windows side, so both the endpoint and gateway.json are reached differently — see If you are running inside WSL below.

Inputs

• set_effects: either effects[] with 1-32 unique effect IDs (each effectId + enabled, optional params), or action: "restore_previous_live".

• submit_file_processing: _version: 1, absolute inputPath, 1-32 unique effects[]; optional batchId, outputFolder, outputPath. There is no overwrite input — a fresh collision is rejected, while resume/retry replaces only that job's own partial output.

• list_devices: optional kind. set_active_device: kind + fresh deviceId, plus optional camera width, height, frameRate. set_camera_resolution: fresh camera deviceId, width, height, optional frameRate.

• Do not reuse device IDs from earlier sessions, and do not guess frame rates. Supply frameRate only when the user explicitly specified or selected it; the camera's current frame rate is not the user's choice for a new request.

Which tool to run commands with

Use terminal for shell commands and execute_code for Python. Never call browser_exec — its code parameter makes it look like execute_code, but it runs that code inside a browser session and opens Chrome. No task in this skill uses a browser.

Connecting

MCP client identity

In this skill, “MCP client” means the current agent runtime executing this skill—not a separate application, CLI, profile, agent, or session. This definition applies throughout the skill.

Do not conclude that no MCP client exists merely because Broadcast tools were not preloaded. Do not search client configuration files, invoke another client such as Claude Code, use a browser, browser-based MCP connection, browser automation, or browser-based remote debugging, delegate to another agent or session, or ask whether another MCP client is installed.

Streamable HTTP is the default and recommended transport. Register the gateway with your MCP client and let the client speak the protocol. Do not hand-roll HTTP requests — it is a normal Streamable HTTP MCP server, and your client already handles protocol version and transport. Add it to your MCP client configuration:

{
  "mcpServers": {
    "nvidia-broadcast": {
      "type": "http",
      "url": "http://127.0.0.1:18100/gateway"
    }
  }
}

Or, for clients that register servers from the command line:

<mcp-client> mcp add --transport http nvidia-broadcast http://127.0.0.1:<port>/gateway

Substitute the client's own command for <mcp-client> and the resolved gateway port for <port>; subcommand and flag names vary by client, but the three values being registered are the same ones in the entry above.

18100 is the default port and is correct on almost every install. No API key or header is required for loopback MCP clients. This URL and port are for the client's configuration, not for connecting directly.

If the default port does not work

The gateway takes the first free port in 18100-18109 and publishes the one it actually bound in %APPDATA%\nvidia-broadcast\gateway.json — base64, decoding to { "port": <number> }. Re-read that file on every retry rather than caching the port; a restart can move it, which is the one case where a registered URL goes stale.

1. Before launching or registering the gateway, read the executable's ProductVersion without launching it. If the executable is not there, NVIDIA Broadcast is not installed. If it is 2.2.x or older, that build has no MCP gateway and no amount of retrying will produce one. Either way, stop the connection sequence, tell the user what you found, and offer to install or update it — see Installing or updating NVIDIA Broadcast below. If they decline, or if installing is genuinely impossible from here — no Windows interop, no PowerShell — point them to https://www.nvidia.com/broadcast-app/ and stop. An earlier failed attempt is not one of those reasons, and neither is a download that had to be retried.

2. Check whether NVIDIA Broadcast.exe is running. If it is not, launch it by running the bundled launcher script — the primary launch command. Use the security-policy fallback in rule 1 under Hard rules only if policy blocks the script:

   Copy

   powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<skill_dir>\scripts\launch_broadcast.ps1"

   <skill_dir> is the absolute path in the skill_dir field of the skill_view result you already have. Run it with the terminal tool. Never with browser_exec — it takes a code parameter just like execute_code, but it runs that code inside a browser session and will open Chrome. Nothing in this skill ever needs a browser. Except for the security-policy fallback in rule 1 under Hard rules, do not write your own launch command or invoke NVIDIA Broadcast.exe directly with subprocess.run, check_output, Start-Process -Wait, or any command that waits for or captures output from the Broadcast process. Never launch a second copy when the process is already running.

3. Whether Broadcast was already running or was just launched, retry for up to 60 seconds: reread and decode gateway.json, then register http://127.0.0.1:<port>/gateway through the MCP client. If nothing answers, use the restart response in hard rule 4 and stop.

   Discovery is exactly these two places and nothing else: gateway.json and ports 18100-18109. Do not search the filesystem for gateway or config files, and do not read environment variables looking for an endpoint or credential — the loopback gateway publishes its port only in gateway.json and needs no key. When both places come up empty, stop endpoint discovery.

   Probe only through your MCP client. Register the candidate URL and let the client connect; a failed registration is the probe result. Never reach the gateway from a shell: no command-line web clients, no throwaway request scripts, and no scanning the port range yourself — see Safety and scope for the full list of prohibited alternatives. If your client cannot register MCP servers at runtime, follow If your client cannot register MCP servers below. Not being able to probe never licenses shell tooling as a substitute.

If your client cannot register MCP servers at runtime

Some clients only load MCP servers from a config file at startup. That is a client configuration problem, not a Broadcast problem, and it is never a reason to fall back to "just turn it on in the app yourself" without checking anything. Do the version check in step 1 first — it reads the filesystem and needs no MCP client — then report whichever of these you actually found:

• Broadcast is missing, or is 2.2.x or older. Offer to install or update it exactly as below. Installing needs no MCP client, and it is worth doing before any config change.

• A 2.3+ build is installed. Nothing is wrong with Broadcast. Tell the user to add the gateway to their MCP client's configuration and restart the client, quoting the entry from Connecting with the port you resolved. Say plainly that you cannot drive Broadcast until they do.

Name which of the two it is. "The gateway isn't available to this session" on its own leaves the user unable to tell whether the app is missing, too old, or merely unconfigured — and sends them off to click through the UI when one config line, or an install, would have fixed it for good.

If you are running inside WSL

The gateway runs in the Windows Broadcast process, so before registering anything establish that 127.0.0.1 in the distro really is Windows loopback, and read the port through the mounted Windows drive. Full procedure in references/connection.md; in short:

1. Detect WSL from /proc/sys/kernel/osrelease — it contains microsoft or WSL. Do not read environment variables to decide this.

2. Check wslinfo --networking-mode. On mirrored — or a WSL 1 distro — loopback is shared, so register http://127.0.0.1:<port>/gateway exactly as on Windows. On nat (the default) the gateway is unreachable from the distro: stop, tell the user, and offer mirrored networking, an MCP client running on Windows, or a tunnel terminating on Windows loopback. Never substitute another address for loopback — not the nameserver in /etc/resolv.conf, the default route from ip route, nor $(hostname).local; nothing is published off loopback and the gateway rejects every non-loopback Host by design.

3. Go through Windows interop for the rest: wslpath "$(cmd.exe /c 'echo %APPDATA%' | tr -d '\r')" to reach gateway.json, and powershell.exe -NoProfile -Command '...' to launch, version-check, and install. If the Windows drive is not mounted or powershell.exe is missing, say so and stop — do not search the Linux filesystem for gateway.json and do not look for a Linux-side substitute; ask the user to start Broadcast on Windows.

See references/connection.md for the version-check command, endpoint discovery, startup, access, WSL specifics, and rate limits.

On connect, the server's instructions already list the exact effectIds available right now, grouped by section, and the set_effects schema constrains effectId to that live set. So you can act immediately — you do not need a discovery call first.

Installing or updating NVIDIA Broadcast

Only when the version check above found no executable at the standard path, or a 2.2.x-or-older build. Never as a workaround for any other failure, and never as a side effect of an unrelated request. Full procedure, commands and failure modes in references/installation.md.

1. Ask what is available. GET https://ota.nvidia.com/release/available?product=rtxb&channel=OFFICIAL&version=$installed&cpuArchType=$arch, where $installed is the installed ProductVersion (0.0.0.0 when Broadcast is not installed) and $arch is aarch64 or x86_64, read from the registry as shown next — never chosen or defaulted. Substitute both values; never send the names themselves. Check both before sending — $installed a dotted version number, $arch exactly aarch64 or x86_64. The service never rejects a bad value: it answers [], which reads as "nothing newer". Read the architecture from the registry, not the process — $env:PROCESSOR_ARCHITECTURE says AMD64 inside x64 emulation on Windows on ARM, which fetches the wrong installer. Use $native = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" -ErrorAction Stop).PROCESSOR_ARCHITECTURE, map AMD64 or x86→x86_64 and ARM64 or ARM→aarch64 into $arch, and throw on anything else — never default to one. Those two values are the only ones the service accepts, and each serves a different installer. The reply is a list of applicable builds, newest first and already filtered to versions above the one you sent — take the first element. An empty list means there is nothing to install; say so and stop, it is not a failure to retry. Distinguish that from a call that never completed, which is a network error and is retryable.

2. Ask the user, and wait. Name the build and size, say it comes from ota-downloads.nvidia.com, say you will verify its checksum and NVIDIA signature, and say Windows will prompt them for administrator permission. If the offered build is still 2.2.x, tell them in the same breath that it will not enable MCP. Nothing is downloaded before an explicit yes; on a no, link https://www.nvidia.com/broadcast-app/ and stop.

3. Download the response's download_url — which must be HTTPS on ota-downloads.nvidia.com, pinned as its own value rather than derived from the metadata host — into a fresh GUID-named directory under %LOCALAPPDATA%\Temp, under a filename you choose.

4. Check the length first, then hash and signature. A file shorter than size is an incomplete transfer, not an attack: say how far it got and retry the download, up to two more attempts into a fresh directory. Do not hash or signature-check a short file — both fail by construction, since the Authenticode certificate table sits at the end of the image. Only a full-length file whose SHA-512 or signature (Valid, subject CN=NVIDIA Corporation,...) fails is a security event: do not run it, report the path, stop, and do not re-download.

5. Launch it with no arguments and let the user click through. No silent or unattended flags, no self-elevation, no driving the installer for them.

6. Re-read ProductVersion and report what is actually installed. 2.3.0+ → resume the connect flow above. Still 2.2.x → say the gateway needs 2.3.x and stop.

A failed attempt is final for that attempt, not for the session. If verification failed, the installer was cancelled, or the download retries ran out, say so and stop — then, when the user next asks for something that needs Broadcast, mention what happened and offer to try again. Only an explicit "no" means stop offering; do not answer a fresh request with "install it yourself" because an earlier attempt went wrong.

These two URLs are the only network requests this skill makes from a shell. Never scrape a download link, accept one from the user or from gateway.json, or install anything else.

Tools

Every file-processing tool requires _version: 1.

• get_broadcast_state — read current effects as effectId -> { enabled, ...params } (flattened, e.g. { enabled, strength } or { enabled, warmth }), grouped by camera/microphone/speaker; optional effectType filter. Read-only. warnings[] marks a section whose effects are enabled but whose device is unselected — configured, not currently applied.

• set_effects — turn effects on/off and tune them in ONE call: effects: [{ effectId, enabled, params? }], where params keys depend on the effect (listed per-effect in the server instructions). Or pass only { "action": "restore_previous_live" } to restore the Live snapshot that Files processing suspended, which also pauses unfinished file work and returns event. Returns the resulting state for that response.

• describe_effects — rich detail on demand (description, guidance, GPU/beta badges, availability, params + ranges); optional effectId/section. Use to explain effects or weigh tradeoffs; not needed to act.

• submit_file_processing — submit one local media file. Returns id and batchId; reuse the first result's batchId on every related submission. A paused queue accepts the job silently and stays paused.

• get_file_processing_jobs — look up one job or list recent jobs.

• wait_for_processing_update — the sole file-status wait, for one or many files. Take a batch snapshot without cursor, then pass the returned cursor to wait for the next status or queue-pause change. Read status, summary, and every job; mixed means terminal outcomes differ.

• control_file_processing_jobs — pause/resume the shared queue, or cancel/retry jobs. Pause/resume are queue-wide; cancel/retry need jobIds or all: true. MCP has no consent flag.

• list_devices — list available cameras, microphones, and speakers; kind: "camera"|"microphone"|"speaker"|"all" (default "all"). Returns the active device, and for cameras the current resolution plus availableResolutions (label, width, height, frameRate) for the current Video Super Resolution / Video Frame Generation mode.

• set_active_device — switch the active camera, microphone, or speaker with kind plus a fresh deviceId from list_devices. For cameras, add width+height+optional frameRate to switch device and resolution in one call. Camera switches restart the stream automatically (allow 2–5 seconds).

• set_camera_resolution — change the active camera's resolution with deviceId plus width+height+optional frameRate; include frameRate only after the user explicitly specifies or selects it. When FPS is unspecified, omit frameRate so the gateway can accept a unique mode or return the available choices for an ambiguous size.

Invalid requests — including unavailable or ambiguous resolutions — return a gateway tool error before anything changes. How to read the success-path fields (success, alreadyActive, alreadySet, frameRateMismatch, failed[], skipped[]) is under Instructions.

Effect ids and params mirror the app's UI (e.g. "Virtual key light" → virtual_key_light with warmth). The exact ids + each effect's params are in the server instructions. See references/effects.md.

For file processing, nest every effect's options under params, exactly as with set_effects. Frame Generation accepts multiplier 2|4 and model "performance"|"balanced"|"quality".

Studio Voice microphone profiles

Set the Studio Voice profile through params.micProfile in either set_effects or submit_file_processing. Read the capability-aware enum from the tool schema or server instructions; the current supported profiles are default, bright, full, and warm. Do not send flat, colored, or thin when they are absent from the advertised enum.

Examples

Complete tool calls — single and combined effects, per-effect params, background replace, frame generation, Studio Voice profiles, restore_previous_live, state reads, device switches and resolution changes — are in references/examples.md. Load it when you need the exact JSON shape.

Worked flows

Multi-step tasks have an expected shape. Follow it exactly.

Several files as one batch

1. Submit the first file with no batchId — the response creates one:

   Copy

   { "name": "submit_file_processing", "arguments": { "_version": 1,
     "inputPath": "C:\\Users\\me\\Videos\\a.mp4",
     "effects": [{ "effectId": "background_blur", "params": { "strength": 0.6 } }] } }

   Keep the returned batchId.

2. Submit every other file with that same batchId.

3. Take one snapshot for the whole batch — omit cursor:

   Copy

   { "name": "wait_for_processing_update", "arguments": { "_version": 1, "batchId": "<batchId>" } }

4. While status is queued or in_progress, call it again with the same batchId plus the cursor the previous response returned, and an optional timeoutMs.

5. Stop at a terminal status — completed, failed, cancelled, or mixed — then report summary and name which files landed in which outcome from jobs. mixed is not success.

Do not wait once per file, and do not poll get_file_processing_jobs in a loop.

Switch camera and set its resolution

1. List first — IDs and available modes change between turns:

   Copy

   { "name": "list_devices", "arguments": { "kind": "camera" } }

   Take the camera's id, then pick a row from that camera's availableResolutions rather than assuming a size is supported. If the size you want appears at more than one frameRate, ask the user which — do not choose for them. The current FPS does not count as an explicit user choice.

2. After the user specifies or selects an FPS, switch device and resolution in ONE set_active_device call, passing kind, the deviceId from step 1, width, height, and the chosen frameRate. If FPS was not specified and the size has only one advertised rate, frameRate may be omitted.

3. Report from that response: check success, then use device and resolution. alreadyActive: true means nothing changed. success: true with frameRateMismatch: true means the size applied but the frame rate differs — tell the user which FPS is actually live.

Do not follow with set_camera_resolution (that is a second stream restart), and do not call list_devices again to confirm.

Instructions

• One call, no redundant verify. Put every effect you want to change in a single set_effects call — including bulk operations (e.g. "turn everything off" = one call with all effectIds enabled:false; disabling an already-off effect is harmless). Its result includes the authoritative state for that call; do not follow it with get_broadcast_state only to confirm.

• Resume saved Live effects through set_effects. Call it once with only action: "restore_previous_live". Do not ask which effects were enabled, pre-read state, or pause the file queue first — Broadcast owns the snapshot. Report event: "live_effects_restored"; event: "no_change" means no suspended snapshot was available or it was already restored.

• Disabled params are ignored. set_effects accepts stale params when enabled:false. To change params while keeping an effect disabled, enable it with the new params then disable it — two calls, because one call rejects a repeated effectId, and the effect is briefly live in between.

• Report what did and did not apply. The batch is ordered but not transactional. success: false carries failed[] ({ effectId, reason } — timeout, unavailable, device_not_selected, file_not_found, or failed) and/or skipped[] ({ effectId, conflictsWith }). Effects absent from both applied. Name which ones did not; never report the batch as done. Retry timeout and unavailable; device_not_selected and file_not_found need corrected user input.

• A missing device selection blocks the effect, on enabling or disabling. It returns reason: "device_not_selected" with deviceType and requiresUserInput: true for that effect; when no requested effect applied for that reason, the whole call fails with error -33201. Tell the user which device type is unselected and ask them to select one. Do not retry unchanged, and do not choose a device on their behalf without saying so.

• Read fresh state when asked. A set_effects response is point-in-time. Never answer a later current-state question from prior tool results; call get_broadcast_state.

• Live state comes only from MCP. For any question about effects or other live state, get_broadcast_state is the only authoritative source. Never open, read, parse, search for, inspect metadata for, or test the existence of AppSetting.json or any other persisted settings file. Do not mention or offer a disk-file fallback, and do not report whether such a file exists. This prohibition still applies when Broadcast is stopped or its gateway is unavailable.

• Use the exact public effectId strings (e.g. virtual_key_light, auto_frame, noise_removal) — do not invent ids or use internal names.

• params values are UI-aligned and normalized 0–1 where numeric (strength, warmth, zoom); modes are enums (e.g. mode: "performance"|"quality").

• For multiple files, use one batch — the shape is under Worked flows. Never infer earlier outcomes by waiting only for the last job.

• Read batch outcomes literally. completed means every file completed; mixed means terminal outcomes differ. Report the summary and affected files, never “all passed” when any job failed or was cancelled.

• Treat cancellation as final until the user asks. When a job is cancelled with reason: "cancelled_by_user", report it and stop. Never retry automatically. If the user explicitly asks afterward, call retry with that job's exact jobIds; do not use all, resubmit, or create a replacement.

• Never auto-resume a user-stopped queue. When batch status is paused_by_user, ask in the agent conversation. Only after an explicit yes, call ordinary queue-wide resume; never send a consent flag.

• Retry failed jobs whose recovery is retry; all: true never retries cancellations. Read the returned event and jobIds; if retry returns no_change, stop and report it instead of submitting replacements.

• Every tool error carries concise text plus structuredContent.error, schema rejections included, so one parse path covers all of them; JSON-RPC protocol failures use a top-level error instead. When data.requiresUserInput is true, stop and ask the user — ambiguous_frame_rate (with data.frameRateOptions) means ask which fps, device_not_selected means ask them to select that device, file_not_found means ask for a real local path. Never substitute a value of your own.

• Read error.retryable before giving up. -32602 means your arguments were wrong and will stay wrong; fix them. -32603 with retryable: true means the app was busy or not ready — the same call may well succeed shortly, so back off and retry rather than reporting failure.

• Always call list_devices fresh — every time the user asks what is available, and before every set_active_device or set_camera_resolution to get the current deviceId. Devices can be plugged or unplugged between turns; never reuse an ID from an earlier turn or session.

• Never infer an unspecified frame rate. The camera's current FPS, a previous setting, the first advertised mode, and 30 FPS are not permission to choose that rate. If list_devices shows multiple FPS values for the requested size, stop before a setter call, present those values, and ask the user to choose. If ambiguity is not known yet, call the setter with width+height and omit frameRate; when it returns requiresUserInput: true with frameRateOptions, present those options and ask. Supply frameRate only after the user explicitly specifies or selects it, then retry.

• Prefer one set_active_device call with resolution over two calls. Switching camera and changing resolution together saves one stream restart and is faster.

• One call, no verify (devices). After a successful set_active_device or set_camera_resolution, use device / resolution from that response — do not follow with list_devices. alreadyActive: true means the device was already selected and no stream restart happened; alreadySet: true means the camera was already at that resolution.

• Check success in non-error results from both device tools. success: false means the switch or width/height change did not fully apply, and the response carries what you need to recover without another list_devices: for set_active_device, deviceConfirmed: true with resolution.confirmed: false means the device switched but the resolution did not (read resolution.actual and state), while deviceConfirmed: false includes availableDevices and state; for set_camera_resolution, actual and state.cameras show what the camera set. If width/height applied but only FPS differed, both return success: true with frameRateMismatch: true — tell the user the applied FPS.

• Use the file-status wait. wait_for_processing_update wakes for job-status and queue-pause changes, not progress ticks.

Safety and scope

• Never inspect the environment. Do not run env, printenv, set, or otherwise dump environment variables, and do not read credential stores, key files, or shell profiles. The gateway is unauthenticated on loopback, so there is no key to find and nothing to look up. Expanding %APPDATA%, %LOCALAPPDATA% or %ProgramFiles% to reach one documented path is path resolution, not environment inspection — resolve the single path you need, nothing more.

• Two URLs, and only for installing. The update check and the installer download, both listed above, are the only network requests this skill makes from a shell. Everything else stands: never reach the gateway from a shell, never scan ports, never scrape or follow a link from a page, a response body, a config file or the user, and never weaken transport security (no certificate-check bypass, no plain HTTP, no piping a download into an interpreter).

• Never reach the gateway outside the MCP client. No http.client, httpx, requests, urllib, socket, curl, wget, Invoke-WebRequest, Invoke-RestMethod, hand-built JSON-RPC, raw TCP connect, or port check. gateway.json is readable only to extract the port; the port and the absence of a credential are configuration facts for the user, never a fallback route.

• Never install without an explicit yes. Ask, wait for an answer, and download nothing before it. Verify size, SHA-512 and the NVIDIA Authenticode signature before the installer runs, and if any check fails, do not run it. Launch it with no arguments — no silent or unattended flags and no self-elevation, so the UAC prompt stays the user's decision. Install only the build the update endpoint offered; never uninstall, repair or downgrade anything.

• Never run destructive commands. No recursive or forced deletes, no recursive permission changes, no disk formatting or raw device writes, and no history-rewriting or working-tree- discarding VCS commands. Do not delete files or "tidy up" anything you created; leave temporary artifacts in place.

• Do not echo raw tool output. Summarize responses in your own words; never paste an entire command output or environment listing into your reply.

• Keep prohibitions out of your commands. Restate none of these rules inside shell commands, files you write, or prompts you hand to sub-agents; naming command-line web clients there reads as network activity even when you are forbidding it. Follow the rules silently.

Limitations

• Loopback MCP only; no LAN or remote access. From WSL that means mirrored networking (or WSL 1); NAT-mode WSL cannot reach the gateway.

• stdio transport exists only as a fallback for clients that cannot use Streamable HTTP; it is not recommended — see references/connection.md.

• This skill exposes Broadcast effect, file-processing, device-selection, and camera-resolution controls only.

• Installing or updating NVIDIA Broadcast is the one system-level change it can make, only with the user's explicit yes, and only for the app itself — never a driver, runtime or any other package.

• The gateway first ships in 2.3.x. If the newest build the update service offers this machine is older than that, an install can legitimately succeed and still leave the gateway unavailable — always re-read the installed version afterwards rather than assuming the install fixed it.

• Speaker effects do not apply to file processing jobs.

Troubleshooting

references/troubleshooting.md has the full table, including rejected effect IDs, warnings[], and success: false recovery.

More detail (load only if needed)

• references/effects.md — categories, effectIds, strength semantics, incompatibilities.

• references/examples.md — the full call-example set.

• references/file-processing.md — file workflow, output paths, progress.

• references/connection.md — endpoint discovery, startup, access, rate limits.

• references/installation.md — consent, download, verification, and install of a missing or too-old build.

• references/troubleshooting.md — the full symptom table.

• references/mcp-tool-contract.md — complete public tool contract.