Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Stage Cue Set

stage_cue_set

Attach a menu ahead of time to a scene event like touch, drop, teleport, or near; the panel opens beside the event or in front of the person, and buttons can run page commands.

Instructions

Attach a menu ahead of time to something the person will do (page command: cue). on is a page event type (touch, menu, drop, teleport, waypoint_done, gesture, ...) or 'near'; match {field: value} must hold on that event (strings match by substring); a 'near' cue needs near {position (Blender xyz), radius (default 1.5)}. When it fires the panel opens beside the thing the event names, or at its point, else in front of the person; buttons default to ['OK']. then {button: command} runs that page command on the page directly (no cmd_done for it). once=False keeps the cue after it fires; ttl_s expires it. Kept per scene in cues.json. The id is cue (the page also reads name), else a new one. One cue fires at a time. Page replies {id, waiting}. Emits (later, when it fires): cue_fired, panel_shown, panel_answer, panel_closed, cue_answer, voice_error.

Input Schema

NameRequiredDescriptionDefault
onYes
cueNo
nearNo
onceNo
textNo
thenNo
matchNo
sceneYes
titleNo
ttl_sNo
widthNo
buttonsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does so well: it explains where the panel opens, default buttons, then-command execution, once/ttl semantics, per-scene storage in cues.json, single-cue firing, immediate response {id, waiting}, and later emitted events. It does not mention permission requirements, but for a local stage tool this is strong coverage.

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

Conciseness3/5

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

The description is a single dense paragraph with many clauses, packed with necessary detail but lacking structural separation. It is front-loaded with purpose, but the volume of information could be organized more readably; no sentence is truly wasteful, but the density reduces scannability.

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?

Given 12 parameters, nested objects, no annotations, and an output schema, the description provides substantial context: it explains the cue mechanism, key parameter semantics, storage location, immediate reply, and emitted events. It omits some minor parameter details and explicit sibling routing, but overall it is complete enough for an agent to invoke the tool correctly.

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 0%, so the description must compensate for 12 parameters. It explains the semantics of the most complex ones: on (event type or 'near'), near (position and default radius), match (substring matching), then (button-to-command mapping), once, ttl_s, and buttons default. Minor parameters like text, title, and width are not explained, but the critical ones for correct invocation are covered.

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

Purpose4/5

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

The description states a specific action: attach a menu ahead of time to an event, with 'cue' as the command name. It clearly distinguishes the tool's role as setting up a cue, though it does not explicitly name sibling alternatives like stage_panel_show or stage_ask.

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

Usage Guidelines3/5

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

The description implies usage via 'attach a menu ahead of time to something the person will do', giving a context for when to use it. However, it offers no explicit when-not-to-use guidance or comparison to similar tools such as stage_panel_show or stage_ask.

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