Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Stage Surface

stage_surface

Display an image, video, text, or live camera feed on every mesh of a scene material as flat unlit surfaces; clear restores original materials.

Instructions

Show an image, a video, text or a live camera on every mesh of a material, now (page command: surface): slides on a whiteboard, a video backdrop, a teleprompter, a monitor with the camera on air, screens on desks. The meshes draw flat and unlit (a screen glows; glow 0..1 dims it) until clear=True gives them their own material back (clear without material: every surface). Not saved to the scene: a re-exported room gets its surfaces back, another scene starts with none. The surface keeps its mesh's shape (aspect measured from its UVs, or aspect= width / height); px is the long side in pixels. One source: image= or video= a file inside the scene folder (path relative to it, e.g. "slides/s01.png"), placed by fit 'contain' (whole, on background), 'cover' (filled, cropped) or 'stretch'; a video plays from start= seconds, loops unless loop=False, silent unless sound=True. text= wrapped to the width, lines= lines on the surface at once, scroll= lines a second (0: still), line= the top line to start at, color, background, align left | center | right, font. camera= a camera in the scene, rendered fps times a second at the surface's aspect with the camera's horizontal field of view (each feed costs a render of the room: keep fps low in the headset). object= instead of material: that object's one material. In a stage_capture setup (with at_song for timing) a video follows the film's time and a camera renders every frame. Errors: no such material or camera, a file that is not in the scene folder, no source. Page replies {surface, source, meshes, px, aspect, size?, text_lines?, on} or {cleared, on}. Emits: surface_set, surface_cleared, surface_lost (a reload could not put one back).

Input Schema

NameRequiredDescriptionDefault
pxNo
fitNocontain
fpsNo
fontNosans-serif
glowNo
lineNo
loopNo
textNo
alignNoleft
clearNo
colorNo#ffffff
imageNo
linesNo
sceneYes
soundNo
startNo
videoNo
aspectNo
cameraNo
objectNo
scrollNo
materialNo
backgroundNo#000000

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so richly: meshes draw flat and unlit, glow dims them, clear=True restores material, surfaces are not saved to the scene, camera feeds cost a room render, and errors and emitted events are listed.

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 dense but front-loaded and contains little wasted filler for a 23-parameter tool. However, it is a long run-on block rather than clearly structured sections, which makes scanning harder than necessary.

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?

The tool is complex, has no annotations, and has 23 parameters, but the description covers source types, placement, playback, text controls, camera cost, scene persistence, errors, page replies and emitted events. Since an output schema exists, the return-value detail is extra but not essential.

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

Parameters5/5

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

Schema description coverage is 0% across 23 parameters, so the description must compensate, and it largely does. It explains px, fit modes, aspect, video start/loop/sound, text wrapping, lines, scroll, line, color, background, align, font, camera fps, object versus material, glow, and clear semantics.

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 opens with a specific verb and resource: showing an image, video, text or live camera on every mesh of a material. It immediately distinguishes the surface behavior from a regular material and gives concrete use cases such as slides, video backdrop and teleprompter.

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 context for when to use the tool, including the page command 'surface', stage_capture timing, and the clear=True behavior. It does not explicitly compare against sibling tools such as stage_material_set or stage_object_set, so it falls short of full alternative routing.

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