Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Stage Asset Install

stage_asset_install

Add scenes, manifests, or 3D assets like actors and trees to a live stage environment. This tool pins files as functional scene nodes, allowing the host server to read and integrate the data directly into the active scene context.

Instructions

Put a file into a live scene where the stage reads it (never cp, Copy-Item or a script into scenes/). kind: "scene" (scene.glb, a new export of the room), "manifest" (manifest.json, its piece list), "actor" (a body, actors/.glb; name= defaults to the file's name; a derived scene's bodies go to its world.json "assets" scene), "tree" (trees/tree_.glb or its tree_.json; name= tree_). A prop is not a file: it is a node of scene.glb, pinned with stage_prop_pin. A file already there is kept in the scene's history/ (nothing is deleted). scenes= the scenes folder when no server runs. An open page takes it best effort: scene and manifest reload the room (page command reload; the page also does it by itself when both files changed), a tree reloads the trees (trees_reload); a body is read when a person is first cast to it (stage_world update={"actors": {...}}), and a body the page already showed changes at the next page load. In VR a room reload is felt: ask first (stage_ask).

Input Schema

NameRequiredDescriptionDefault
fileYes
kindYes
nameNo
sceneYes
scenesNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.4/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: files are moved to the scene's history/ rather than deleted, live-page effects are described per kind (scene/manifest reload the room automatically when both change, tree triggers trees_reload, a body is read on first cast via stage_world), a body already shown only changes at next page load, and a VR room reload is felt so stage_ask must come first. That is unusually complete behavioral disclosure for a mutation tool.

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?

Front-loaded and free of filler, but written as one dense run-on paragraph mixing kind semantics, page-refresh behavior, and VR etiquette. Every sentence earns its place, yet the absence of structure makes it harder to parse than it needs to be for a five-sentence operational rule set.

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?

An output schema exists, so return values need no explanation. For a complex install tool the description covers kinds, retention, live-reload consequences, and the VR safety step; only failure modes and the precise meaning of the required 'scene' argument remain unstated.

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 coverage is 0%, so the description must compensate, and it largely does: it defines the kind values, the name= default and tree naming convention, and the scenes= fallback when no server runs. The 'scene' parameter's meaning is only implied, and 'file' is left to common sense, but the ambiguous parameters are covered.

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?

States a specific verb and resource (put a file into a live scene where the stage reads it) and immediately distinguishes itself from raw copying and from stage_prop_pin, which handles props that are not files. An agent can tell what this tool is for without opening the 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 negative guidance ('never cp, Copy-Item or a script into scenes/'), enumerates the four kind values with what each one means, and names the alternative for props (stage_prop_pin) and the required pre-check in VR (stage_ask). It stops short of routing to sibling tools for export/refresh cases, but the when-to-use context is clear.

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