Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Stream Visual

stream_visual

Configure stream visuals, background, area, and capture settings in one call to avoid repeated encoder restarts and live blips.

Instructions

Set the stream's picture with raw numbers. While live this restarts the encoder: a 2-3 s blip on every site, so set everything in one call. mode: page (the visual page, drawn from the set's levels as stream_scene sets it: the one to change live with no blip), cqt (a piano-roll spectrum), spectrum (bars), waves, scope (a stereo vector scope) or none. colors: ['#rrggbb', '#rrggbb'] for spectrum and waves. background: '#rrggbb', or image: a still behind it, or window: the title of a window to capture (a page the agent draws, the VR stage mirror). area: [x, y, w, h] of the visualizer, fractions of the frame. chat_overlay: the newest chat line in the corner. width/height/fps: 1280x720 at 30 by default. video_kbps: 4500 (Twitch takes 6000 at most). encoder: auto (NVENC when the GPU has it), nvenc or x264. capture: how a window (or the page) is captured: auto (wgc where ffmpeg has it), wgc (Windows Graphics Capture: GPU-drawn pages such as the stage's WebGL, and a covered window, come through; the page draws on the GPU) or gdi (gdigrab: a GPU-drawn window comes out blank, so the page draws in software). A Chrome or Edge window is cropped to its web content. Look at the result with stream_look.

Input Schema

NameRequiredDescriptionDefault
fpsNo
areaNo
modeNo
imageNo
widthNo
colorsNo
heightNo
windowNo
captureNo
encoderNo
font_sizeNo
audio_kbpsNo
backgroundNo
text_colorNo
video_kbpsNo
chat_overlayNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the disruptive encoder restart and its 2-3 s multi-site impact, capture-mode failure modes (gdi renders GPU-drawn windows blank), auto-cropping of Chrome/Edge windows, and the Twitch 6000 kbps ceiling. These are exactly the operational consequences an agent could not infer from the schema.

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 the highest-stakes fact (the live blip) before the parameter catalogue, and nearly every clause carries real information for a 16-parameter tool. The downside is density: it reads as one long run-on block, making individual parameters harder to scan than a lightly structured list would.

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 16-parameter, zero-coverage, no-annotation tool, the description covers the behavioral risk, the enum-like value sets, and formatting conventions, and it need not explain return values because an output schema exists. Only the undocumented font_size, text_color, and audio_kbps leave an agent guessing about the full parameter surface.

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?

With 0% schema description coverage across 16 parameters, the description compensates strongly: it enumerates mode values (page/cqt/spectrum/waves/scope/none), encoder options with a hardware-selection default, capture options with tradeoffs, and units/format for area ('fractions of the frame'), colors ('#rrggbb'), and bitrates. Three parameters — font_size, text_color, audio_kbps — receive no explanation at all, which keeps it from a 5.

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?

Opens with a concrete verb and object ('Set the stream's picture with raw numbers') and immediately distinguishes itself from related tools by naming stream_scene (source of the visual page) and stream_look (verification). An agent can tell this is the raw configuration layer for stream visuals versus stream_page/stream_scene 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 Guidelines4/5

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

Gives explicit conditional guidance: setting while live causes an encoder restart with a 2-3 s blip, so 'set everything in one call'; page mode is 'the one to change live with no blip.' It also routes the agent to stream_look to verify results. It stops short of stating preconditions (does the stream need to be running?) or when to prefer stream_page over this tool.

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