Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Stage World

stage_world

Modify scene configuration by reading or updating the world.json structure. Manage parameters like actors, facings, floor, and build details using structured commands.

Instructions

Read a scene's world.json (who plays whom, facings, partners, floor, keep-out boxes, spawn, credits, build), or change it. update= changes only the keys it names and keeps the rest of the file: update={"floor": 0.1}, or update={"actors": {...}} (a key's value is replaced whole, so give the whole actors map; null removes the key, which goes back to its default). world= replaces the whole file: every key left out goes back to its default (load sets, props, faces, grab, gestures and the build are lost), so use update= to change a key. Not both. Either is checked first, and the old file is kept in the scene's history/. scenes= the scenes folder when no server runs. An open page takes it at once (page command world_reload: facings, partners, floor, grab and actors apply now; unloaded sets, props, faces and keep-out boxes are redone; the reply lists what changed and what was redone); with no page open it applies at the next load. Never edit world.json by hand.

Input Schema

NameRequiredDescriptionDefault
sceneYes
worldNo
scenesNo
updateNo

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, the description carries the full burden and does so richly: validation order, old file kept in history/, immediate application when a page is open versus next-load behavior, and what the reply reports. It even warns never to edit world.json by hand, which is exactly the kind of consequence disclosure a mutation tool needs.

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?

Dense but front-loaded, starting with read-or-change before drilling into update/world semantics. Every sentence carries operational weight, though the single run-on paragraph makes it slightly harder to scan than a few separated clauses would.

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?

Complete for a 4-parameter mutation/read tool: it covers parameter modes, validation, file history, page application behavior, and the no-server case. Since an output schema exists, it need not detail return values, and its note that the reply lists changed/redone items is sufficient.

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 coverage is 0%, but the description compensates fully: update's whole-map replacement and null-deletes-key semantics, world's full-replace-and-default behavior, scenes as the no-server folder, and scene as the target. The nested-object complexity is explained rather than left to the schema.

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?

States a specific verb and resource: read or change a scene's world.json, enumerating its contents (actors, facings, partners, floor, keep-out boxes, spawn, credits, build). The tool is clearly distinct from siblings, but no sibling is named to help an agent route between stage_world, stage_scene_reload, or stage_scene_new.

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

Usage Guidelines5/5

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

Explicitly defines when to use update= versus world=, warns 'Not both', and explains that update only changes named keys while world resets everything. It also covers the scenes= fallback when no server runs, leaving the agent no ambiguity about the correct parameter path.

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