Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Stage Control Set

stage_control_set

Change which joint or object drives a selected actor body part during a Follow session, using hold, effector, pin, mimic, or default modes to retarget motion.

Instructions

Change what drives one part of a person, now, during a Follow too (page command: control_set). The built-in map stays the base (the user's head drives head and spine, the wrists the arms, the fingers the fingers, legs step or sit); a drive takes one part over. part: a named part of the actor's rig (stage_actor_profile(person) lists them; on people: head, spine, arm_l, arm_r, leg_l, leg_r, fingers_l, fingers_r, thumb_l, index_l, ...). mode: 'hold' keeps the pose it has now (riding with the body); 'effector' (arms and legs) reaches for a target that moves as joint= moves, relative to where both were when it bound (his feet acted by the user's hands: part 'leg_l', joint 'hand_l'), scale= multiplies the motion, touch=True shows a ball in front of the user and binds when that hand reaches it; 'pin' (arms and legs) reaches for at= (an object, [x, y, z] in Blender metres, or 'here') and stays; 'mimic' copies the turn of joint= since it bound, spread down the chain, or 1:1 with a list of joints, one per bone; 'default' gives the part back to the built-in map. joint: 'head', 'hand_l', 'hand_r', or 'hand_r:' (e.g. hand_r:index-finger-tip). A hand that drives another part lets go of its own arm and fingers (they hold). Drives last for the page's session; stage_control_map applies saved ones. Page replies {person, part, mode, joint, waiting, drives}. Emits: control_set, control_bound.

Input Schema

NameRequiredDescriptionDefault
atNo
modeNodefault
partYes
jointNo
scaleNo
sceneYes
touchNo
personYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.2/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 behavioral burden and does so richly: it explains that the built-in map remains the base, that a drive overrides one part, how each mode behaves, that 'a hand that drives another part lets go of its own arm and fingers,' and that drives last only for the page session. It also discloses the page reply shape and emitted events. This is strong transparency for a mutation-style tool.

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 purpose is front-loaded in the first sentence and nearly every clause carries operational detail. However, the description is a single dense, semicolon-heavy paragraph with nested parentheticals, which makes it harder to parse than a cleanly structured definition. It is appropriately sized for a complex 8-parameter tool but could be organized better.

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?

For a complex session-control tool with 8 parameters, no annotations, and an output schema, the description covers modes, side effects, persistence, replies, and events well. The output schema reduces the need to explain return values, though the description still does so usefully. It leaves the required 'scene' parameter and permission/error conditions unaddressed, so it is not fully complete.

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, and it defines most parameters: part, mode values ('hold', 'effector', 'pin', 'mimic', 'default'), joint formats, at targets, scale, and touch behavior. It also mentions person via stage_actor_profile(person), but it never explains the required 'scene' parameter. That gap prevents a full 5 despite otherwise rich parameter semantics.

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 first sentence states a specific verb and resource: 'Change what drives one part of a person' during a Follow. It distinguishes this live override from stage_control_map, which 'applies saved ones,' so the agent can tell the two apart without opening schemas. Domain-heavy phrasing around 'built-in map' and 'drive' keeps it below a perfect 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?

The description gives clear context for use: this changes control 'now, during a Follow too,' and notes that 'stage_control_map applies saved ones.' That explicitly routes between live control changes and saved maps. It lacks an explicit when-not-to-use section or prerequisites, so it is not a 5.

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