Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Stage Object Drop

stage_object_drop

Stand an object back up with its original Blender tilt and heading, then drop it under gravity onto the highest surface beneath its footprint as one undoable edit.

Instructions

Stand the object back up (its tilt as Blender had it, heading kept) and let it fall under gravity onto the highest surface under its footprint, as one undoable edit (page command: drop). The reply comes before the fall animation ends. Lights, aimed objects and big building parts do not drop, and nothing under it means no drop: in both cases onto_y_up is null and no error is raised. Page replies {object, onto_y_up} (the landing height, three Y = Blender Z, metres). Emits: transform_end once it lands (via claude).

Input Schema

NameRequiredDescriptionDefault
sceneYes
objectYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A3.6/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 well: it discloses the undoable mutation, that the reply arrives before the animation finishes, the no-drop edge cases, the null return in those cases, the return shape and coordinate convention, and the transform_end emission.

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 definition is information-dense and front-loads the action before covering timing, edge cases, return values, and events. Most sentences earn their place, though the wording is packed and could be split for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Behaviorally it is strong for a mutation tool with no annotations, especially around edge cases and return behavior. But the input schema is completely undocumented, and the description does not compensate for the missing scene/object parameter semantics, leaving a real gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and neither required parameter has a description. The text refers to 'the object' and to the page reply, but it never explains what 'scene' means, whether identifiers are names or IDs, or what format 'object' expects. Two required parameters remain largely undocumented.

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 description states a specific action: stand the object upright and let it fall onto the highest surface under its footprint, as one undoable edit. That is a clear verb-plus-resource statement. It does not, however, explicitly distinguish this tool from nearby stage_object_* siblings, so it falls short of the top score.

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

Usage Guidelines3/5

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

Usage is implied by the action and by the note that lights, aimed objects and large building parts do not drop. There is no explicit 'use this when' guidance or named alternative for cases where dropping is not appropriate, so it is minimum viable.

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