Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Stage Follow

stage_follow

Make a camera, light, or drone soft-follow a target live on the page with no code, tuning offset, lag, look, and orbit; stop it any time or read a target's pose.

Instructions

Make an object (a camera, a light, a drone) soft-follow a target every frame, live on the page, with no code (page command: follow); the same follow a behaviour starts with s.follow. target: an object's name, 'person' (the user's eyes: the headset in VR, the view on a desktop) or ':' (a joint of a body the scene shows, e.g. dell:head, dell:pelvis, dell:hand_r; a wrong bone lists some). offset: [right, forward, up] metres from the target, turning with where it faces (space 'target'; a body faces where its hips face), or [x, y, z] Blender metres (space 'world'). lag: seconds to close most of the gap (0 = locked on; 0.3 to 1 reads as a camera operator). look: True aims at the target (the default for cameras and lights), False keeps its turn, a target name or an [x, y, z] point aims there; look_offset [x, y, z] moves the aim point (aim at the chest, not the hips); look_lag smooths the turn. orbit: degrees a second around the target (a drone circling). snap: start on the spot. target=None stops the object's follow. While it follows, its keys on the clock wait. Live only, never saved: bake it into keys for the render with stage_camera_record(source='follow'), then keep. object=None lists what follows what; where= reads a target's pose {location, rotation, quaternion, forward, facing} (Blender metres and degrees) and changes nothing. A reload of behaviours.js ends agent follows. Page replies {object, target, following, waiting?}. Emits: follow {object, target, following, by?, why?}.

Input Schema

NameRequiredDescriptionDefault
lagNo
lookNo
snapNo
orbitNo
sceneYes
spaceNotarget
whereNo
objectNo
offsetNo
targetNo
look_lagNo
look_offsetNo

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?

No annotations are provided, so the description carries the full burden and does so thoroughly: it discloses that follows are live-only and never saved, that the object's keys wait while following, that a behaviours.js reload ends agent follows, and it states the reply payload and emitted event. These are exactly the behavioral traits an agent needs.

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, which is good, but the body is a dense, near-run-on block covering ten parameters without breaks or grouping, making it heavier to scan than necessary. The information earns its place, but the presentation costs readability.

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?

For a 12-parameter tool with no annotations, the description covers the living-follow lifecycle, the listing/reading modes, the render-bake path, and the return/emit contract. An output schema exists and the description still names the reply shape, leaving no material gap for correct invocation.

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%, so the description must compensate and it does — target ('person', '<person>:<bone>' with examples like dell:head), offset (per-axis meaning plus target vs world space), lag (seconds to close the gap), look/look_offset/look_lag, orbit (degrees per second), snap, and space are all given meaning far beyond the bare 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?

Opens with a specific verb and resource: 'soft-follow a target every frame, live on the page.' The scope ('live on the page, no code') is clear, but it never names or contrasts itself against the closely related siblings stage_actor_follow or stage_follow_anchor, so an agent still has to guess which follow tool to pick.

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?

Strong conditional guidance is present: 'object=None lists what follows what', 'where=<target> reads a target's pose', 'target=None stops the object's follow', and 'Live only, never saved: bake it into keys ... with stage_camera_record(source='follow')'. This gives clear when/when-not within the tool's own lifecycle, though it does not route to the sibling follow tools.

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