Skip to main content
Glama
Sign In
Claude ATEM MCP

Claude ATEM MCP

by La8Grt8
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Set Upstream Key DVE Settings

atem_set_usk_dve
Idempotent

Configure an upstream keyer's DVE properties—position, size, rotation, border, mask, and shadow—to create picture-in-picture overlays on an ATEM switcher.

Instructions

Set DVE (Digital Video Effects) properties for an upstream keyer — position, size, rotation, border, mask, shadow.

Use this for picture-in-picture overlays. First set the key type to DVE with atem_set_usk_type, then use this tool to position and size the DVE box.

All values are passed directly to the ATEM protocol (raw units):

  • sizeX, sizeY: 0 to 1.0 (fraction of full frame, e.g. 0.5 = half, 0.33 = third)

  • positionX: -1.0 to 1.0 (horizontal position, -1=left edge, 0=center, 1=right edge)

  • positionY: -1.0 to 1.0 (vertical position, -1=bottom, 0=center, 1=top)

  • rotation: 0-35999 (hundredths of degrees, e.g. 9000 = 90°)

  • crop: 0 to 1.0 (fraction of image to crop from each edge)

Args:

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

  • usk (number): Upstream keyer number (0-based)

  • sizeX (number, optional): Horizontal size 0-1.0

  • sizeY (number, optional): Vertical size 0-1.0

  • positionX (number, optional): Horizontal position -1.0 to 1.0

  • positionY (number, optional): Vertical position -1.0 to 1.0

  • rotation (number, optional): Rotation 0-35999 (hundredths of degrees)

  • borderEnabled (boolean, optional): Show border

  • borderOuterWidth (number, optional): Outer border width 0-1600

  • borderInnerWidth (number, optional): Inner border width 0-1600

  • borderHue (number, optional): Border hue 0-3599

  • borderSaturation (number, optional): Border saturation 0-1000

  • borderLuma (number, optional): Border luminance 0-1000

  • borderOpacity (number, optional): Border opacity 0-100

  • shadowEnabled (boolean, optional): Show drop shadow

  • maskEnabled (boolean, optional): Enable mask

  • maskTop (number, optional): Mask top 0-38000

  • maskBottom (number, optional): Mask bottom 0-38000

  • maskLeft (number, optional): Mask left 0-52000

  • maskRight (number, optional): Mask right 0-52000

Example — 3x2 grid element at top-left, 1/3 size: sizeX=0.33, sizeY=0.33, positionX=-0.33, positionY=0.25

Input Schema

NameRequiredDescriptionDefault
meNoMix Effect bus
uskYesUpstream keyer number (0-based)
sizeXNoHorizontal size (0-1.0, raw ATEM units)
sizeYNoVertical size (0-1.0, raw ATEM units)
maskTopNoMask top edge
maskLeftNoMask left edge
rotationNoRotation in hundredths of degrees
borderHueNoBorder hue
maskRightNoMask right edge
positionXNoX position (raw ATEM units)
positionYNoY position (raw ATEM units)
borderLumaNoBorder luminance
maskBottomNoMask bottom edge
maskEnabledNoEnable mask
borderEnabledNoShow border
borderOpacityNoBorder opacity
shadowEnabledNoShow drop shadow
borderInnerWidthNoInner border width
borderOuterWidthNoOuter border width
borderSaturationNoBorder saturation

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.5.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=true), and the description reinforces it by explaining values go straight to the ATEM protocol in raw units and by demonstrating ranges. It does not state that unspecified optional params are left untouched (partial-update semantics), which matters for a 20-param setter, but overall it adds real context beyond the annotations.

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?

Well front-loaded: purpose, then usage, then units, then example. The downside is the exhaustive 'Args:' block restating all 20 parameters that the 100%-covered schema already documents, which is pure duplication and significantly inflates length.

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 20-parameter mutation tool with no output schema, the description supplies units, ranges, an example, and the required prerequisite, which is close to sufficient. The remaining gap is merge behavior (what happens to parameters not passed) and the mask/atem_set_usk_mask overlap.

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 coverage is 100%, so the baseline is 3, and the description earns above it by decoding values the schema only labels 'raw ATEM units' — e.g. positionX -1=left, 0=center, 1=right, rotation in hundredths with a 9000=90° example, and a worked 1/3-size grid example. Minor noise: it documents a 'crop' parameter that does not exist in the schema.

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?

States a specific verb and resource ('Set DVE properties for an upstream keyer') and enumerates the effects affected (position, size, rotation, border, mask, shadow). It is clearly distinguishable from siblings like atem_set_usk_type and atem_set_usk_sources, which handle different facets of the same keyer.

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?

Gives a concrete use case ('picture-in-picture overlays') and an explicit prerequisite ('First set the key type to DVE with atem_set_usk_type'). However, it never explains why mask parameters live here when a sibling atem_set_usk_mask exists, leaving a routing ambiguity an agent will hit for mask-only edits.

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