Skip to main content
Glama

LiveReacting

by com.livereacting
OverviewDiscussionsAdmin

Add a layer to an existing scene

livereacting_add_layer
Destructive

Add one layer to a scene that already exists. Three types can be created: "videoPlaylist" and "audioPlaylist", which hold a list of files, and "video", which holds a single file. Text, image and interactive layers are readable with livereacting_get_layer but can only be created in the LiveReacting Studio. Use this to put a playlist into a scene that has none -- for example a scene made by livereacting_manage_scene, or a background music track alongside a video playlist. For a NEW scene and its playlist together use livereacting_create_scene_with_playlist instead; that tool also wires the auto-switch that chains a 24/7 channel. For a video or audio playlist, loop defaults to true; pass loop: false for a clip that must play once. The settings are read strictly by type, and the wrong ones are dropped without an error: a "video" layer ignores files, and a playlist layer ignores fileId. settings.files is optional, so a playlist created without it is created empty; send the files here, or fill the layer afterwards with livereacting_set_playlist. If autoSynch is on and the project is streaming, this copies the full saved project configuration to the running stream. It can overwrite changes made only to the live stream, including settings of existing layers. This is NOT idempotent: calling it twice adds two layers. After a timeout, read the scene with livereacting_get_scenes to see whether the layer arrived, rather than calling again. To change a playlist afterwards use livereacting_set_playlist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName for the layer, 19 characters or less. Defaults to a name for the type.
typeYes"videoPlaylist" and "audioPlaylist" play a list of files; "video" plays one file.
sceneIdYesThe scene to add the layer to, from livereacting_get_scenes.
settingsNoWhat the layer plays. The fields differ by type -- see each one.
projectIdYesProject id, from livereacting_list_projects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: settings are read strictly by type and mismatched fields are silently dropped, files being omitted creates an empty playlist, autoSynch can copy the saved project over the running stream and overwrite live-only changes, and calls are not idempotent with a timeout-recovery path via get_scenes. This is far richer than the destructive/idempotent hints alone.

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?

Front-loaded with purpose and type enumeration, and nearly every sentence carries operational value. It is on the long side for a single tool, and the set_playlist guidance appears twice in different phrasings, which is mild redundancy.

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

Completeness5/5

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

With no output schema, the description supplies what an agent still needs: default behaviors, silent-drop failure modes, stream-overwrite side effects, and the correct recovery step after a timeout. For a nested, type-discriminated mutation this is complete.

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 a baseline of 3 is warranted, but the description adds type-dependent semantics the schema only implies: playlists ignore fileId, video ignores files, and loop defaults to true for playlists with loop:false needed for a play-once clip. It stops short of covering name/volume/adPoints behavior, so it is not a full doubling of 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 ('Add one layer to a scene that already exists') and immediately enumerates the three creatable types, noting which layer types must be made in the Studio instead. It explicitly separates itself from livereacting_create_scene_with_playlist and livereacting_set_playlist, so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use cases (scene with no playlist, background music alongside a video playlist) and names the alternatives with the condition that selects them: create_scene_with_playlist for a new scene, set_playlist to modify a playlist afterwards, get_scenes to verify after a timeout. Nothing is left to inference.

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

All LiveReacting toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources