Skip to main content
Glama
Sign In
Claude ATEM MCP

Claude ATEM MCP

by La8Grt8
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Auto Switch On

atem_auto_switch_on

Starts auto-switching to the active speaker by monitoring audio levels, with full-screen, Super Source box, or host-guest hybrid modes.

Instructions

Start auto-switching mode — continuously monitors audio levels and switches to the active speaker automatically, Zoom-style.

Three modes:

  • program (default): Switches the full-screen program input to the active speaker

  • ssrc_box: Updates a Super Source box source to the active speaker — perfect for "host + active speaker" side-by-side

  • host_ssrc: Hybrid mode — host talking → cuts to host full-screen; guest talking → updates Super Source box with that guest AND cuts to Super Source (6000). Perfect for talk shows where the host gets their own shot but guests share a side-by-side with the host.

Fast and responsive like Zoom's active speaker switching:

  • Instant detection — uses real-time audio peaks to detect new speakers immediately

  • Hold time (default 1s): brief confirmation to filter out coughs/bumps

  • Cooldown (default 2s): short pause after switching to prevent ping-pong

  • Smart stickiness — the current speaker uses smoothed audio levels so brief pauses between words don't cause a switch away

Args:

  • mode (string, optional): "program", "ssrc_box", or "host_ssrc" (default: "program")

  • ssrcBox (number, optional): Super Source box to update, 1-4 (default: 2). Used in ssrc_box and host_ssrc modes.

  • guestInputs (array of numbers, optional): Inputs to monitor (default: all inputs 1-8 except host; in host_ssrc mode, host is automatically included)

  • hostInput (number, optional): Host camera input (default: 7). In host_ssrc mode, this is who gets full-screen when they talk.

  • holdMs (number, optional): How long a new speaker must talk before switching, in ms (default: 1000)

  • cooldownMs (number, optional): Minimum ms between switches (default: 2000)

  • transition (string, optional): "cut" or "auto" (default: "cut"). Only used in program mode.

  • me (number, optional): Mix Effect bus (default: 0)

Examples:

  • "Auto switch" → starts following the active speaker (full-screen)

  • "Auto switch box 2 to active speaker" → mode="ssrc_box", ssrcBox=2

  • "Host full-screen when talking, side-by-side when guest talks" → mode="host_ssrc", ssrcBox=2

  • "Auto switch with dissolves" → transition="auto"

  • "Auto switch on all cameras" → guestInputs=[1,2,3,4,5,6,7,8], hostInput=0

Input Schema

NameRequiredDescriptionDefault
meNoMix Effect bus (default: 0)
modeNoMode: "program" switches full-screen, "ssrc_box" updates a Super Source box source, "host_ssrc" host full-screen + guest in Super Sourceprogram
holdMsNoHold time in ms — new speaker must talk this long before switching (default: 1000)
ssrcBoxNoSuper Source box to update (1-4, default: 2). Only used in ssrc_box mode.
hostInputNoHost camera to exclude (default: 7). Set to 0 to include all inputs.
cooldownMsNoCooldown in ms — minimum time between switches (default: 2000)
intervalMsNoLevel check interval in ms (default: 250)
transitionNoTransition type: "cut" or "auto" (default: "cut"). Only used in program mode.cut
guestInputsNoCamera inputs to monitor (default: all 1-8 except host)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.5.0

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations only indicate this is a non-readonly, non-idempotent, non-destructive operation, but the description adds substantial behavioral detail: continuous monitoring, real-time audio detection, hold time, cooldown, and speaker stickiness. It also explains how each mode behaves, which is far beyond the annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and modes, then behavior, arguments, and examples. It is longer than a minimal definition but proportional to a nine-parameter stateful tool, with only minor redundancy around defaults.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex stateful auto-switching tool with nine parameters and no output schema, the description covers modes, timing behavior, defaults, and examples well. It does not describe the return value or explicitly say to use atem_auto_switch_off to stop the mode, leaving small gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all nine parameters, including intervalMs. The description adds useful mode-specific semantics for ssrcBox, hostInput, guestInputs, transition, and examples, though it omits intervalMs from its Args list.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: start auto-switching mode, continuously monitoring audio and switching to the active speaker. It also distinguishes the three operational modes clearly, so an agent can tell this apart from one-shot switching tools like atem_cut_to_active_speaker.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context through mode descriptions and examples, including which mode to use for full-screen, side-by-side, and host/guest talk-show scenarios. It does not explicitly reference the sibling stop/status tools, so the when-not-to-use boundary is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools