ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Stage Panel Show

stage_panel_show

Opens a VR panel with title, text, image, and buttons anchored to the world or the user's body to show notes or ask questions, collecting answers through button pokes or gestures.

Instructions

Open a panel in VR with a title, text, an image (URL) and buttons (page command: panel). anchor='world' (default) fixes it 0.7 m in front of the person: for a note about a place. anchor='body' makes it ride with them, just out of view to the side ('right' or 'left') of where their body faces, so they turn their head to read it and it follows them as they move: for a message to them. seconds closes it by itself; the X closes it. wait defaults to True for a world panel (a question) and False for a body panel (a message never holds the command queue). sender= your name as the person should see it (e.g. "crossroads film"): a chip and border in that name's colour, and a body panel goes on that name's side unless side= says otherwise. It never opens while they are talking (a note recording, the phone gesture, 3 s after a note): it waits, and emits panel_held. The person answers by poking a button, pointing and pinching, or a right thumbs up / down held 450 ms (first / last button). seconds closes it by itself. quiet skips the chime. wait=True BLOCKS the command queue until the answer; wait=False replies at once. The same panel_id replaces an open panel. near is used by the page's own modules as a three.js vector; from a command it is unclear (a JSON list has no x/y/z) and should not be relied on. Page replies {id, answer, via, seconds}, {id, answer: null, why} when closed unanswered, or {id, shown: true} with wait=False. Emits: panel_shown, panel_answer, panel_closed. A yes/no panel (its buttons are yes and no words) whose title or text a standing grant covers is refused: act on the grant and say what you did; override_grant='' shows it anyway and logs the reason.

Input Schema

Name	Required	Default
`near`	No
`side`	No
`text`	No
`wait`	No
`image`	No
`quiet`	No
`scene`	Yes
`title`	No
`width`	No
`anchor`	No	world
`sender`	No
`buttons`	No
`seconds`	No
`panel_id`	No
`override_grant`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Oct 26, 2026

TDQS

A4.1/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: wait=True 'BLOCKS the command queue until the answer', panels are never shown while the person is talking (emits panel_held), the same panel_id replaces an open panel, grant-covered yes/no panels are refused, and skip-the-chime behavior is disclosed. That is exactly the side-effect and gating detail an agent needs before calling.

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?

Purpose is front-loaded and most sentences carry real information, but 'seconds closes it by itself' and the wait blocking rule are each stated twice, and the run-on sentence about talking/answering/quiet is hard to parse. For 15 parameters the length is defensible; the repetition is not.

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?

Blocking semantics, emissions (panel_shown, panel_answer, panel_closed, panel_held), close conditions and refusal behavior are all present, and an output schema exists so return shapes are partly redundant here. Still silent on what `scene` selects and what `width` controls, so it is not fully complete for a 15-parameter tool.

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% across 15 parameters, so the description must compensate, and it explains anchor, side, seconds, wait (including asymmetric defaults), sender, quiet, panel_id, buttons interaction and override_grant semantics. `scene`, `width` and the concrete button payload shape are left undocumented, which is the remaining gap.

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?

Opens with a specific verb and resource: 'Open a panel in VR with a title, text, an image (URL) and buttons.' An agent immediately knows what is produced. It never names a sibling (e.g. phone_panel_show, stage_ask, stage_panel_close) to disambiguate, so it stops short of a 5.

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?

Explicitly routes between the two main modes: anchor='world' 'for a note about a place' versus anchor='body' 'for a message to them', plus when to reach for override_grant. It also warns that `near` 'should not be relied on' from a command. No guidance on choosing this tool over phone_panel_show or stage_ask, which keeps it at 4.

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

Deploy Server