Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Stage Preflight

stage_preflight

Verifies a VR stage is ready for a session or demo by running ordered checks, reporting PASS, BLOCKED, or SKIPPED steps, and showing the verdict in VR or as a caption.

Instructions

Check the stage before a VR session or a demo, on a scratch scene of its own (_preflight, hidden from the page's scene list, overwritten on every run; nothing else is loaded over, moved or deleted). Checks, in order: server (it answers), presence (is someone in VR), allow_rule and guard_hook (read ~/.claude/settings.json and the project's .claude/settings.json and settings.local.json; never writes them), scratch (make or refresh the scratch scene), load (a headless, muted browser opens it and the page's selftest passes), hot_swap (stage_asset_install of a new scene.glb, answered by the page's reload), live_insert (stage_world update= and stage_set_load unload then load, each answered by the page), say (stage_say on the scratch page, a caption) and listen (a synthetic event, marked synthetic, goes round the inbox and stage_listen returns it). Each line is PASS, BLOCKED (with the next step) or SKIPPED. While someone is in VR only the checks that change nothing they see run, and the rest say SKIPPED. The verdict ("Preflight: pass." or "Preflight blocked: .") is shown on the stage: in VR the headset says it out loud; otherwise it is a caption on the open page, never spoken on the computer. port= the stage server (default: the newest one serving a real scenes folder); say=False keeps the verdict off the stage; wait= seconds the test page may take to load; headless=False opens no browser (a page you opened on ?scene=_preflight is used).

Input Schema

NameRequiredDescriptionDefault
sayNo
portNo
waitNo
headlessNo

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 extensively: the scratch scene is hidden, overwritten each run, and nothing else is loaded, moved, or deleted. It also discloses read-only handling of settings files, VR-specific skipping behavior, and whether the verdict is spoken in VR or shown as a caption on the computer.

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 long and dense but front-loads the purpose and check sequence before moving into behavior and parameters. Most clauses earn their place given the complexity, though the single-paragraph format could be more scannable.

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, with many checks, side-effect constraints, and optional parameters, and the description covers all of these. Since an output schema exists, it does not need to explain return values, and the remaining call requirements are sufficiently documented.

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%, so the description must compensate and it does: port identifies the stage server and its default selection rule, say=False keeps the verdict off stage, wait controls test-page load time, and headless=False uses an already-open page on ?scene=_preflight.

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 first sentence gives a specific verb and resource: 'Check the stage before a VR session or a demo,' and immediately scopes it to a dedicated scratch scene. The detailed check sequence and use of sibling tools make it clear this is a preflight validation tool rather than a general stage mutation tool.

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 states the primary situation clearly: before a VR session or demo. It also gives a conditional usage rule for when someone is already in VR, limiting checks to those that change nothing visible. However, it does not explicitly name alternatives or say when not to run preflight.

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