Skip to main content
Glama

add_rigid_body_constraint

Connect two rigid bodies with fixed, hinge, slider, piston, spring, or motor constraints to create joints, doors, and breakable assemblies in Blender.

Instructions

Join two rigid bodies with a physics constraint (glue, hinge, slider, spring, motor).

Both objects need add_rigid_body first. The constraint lives on a new empty, placed at the midpoint unless location is given; HINGE turns around the empty's Z axis, SLIDER and PISTON move along its X.

Args: object1: First rigid body. object2: Second rigid body. type: FIXED (glued), POINT (ball joint), HINGE, SLIDER, PISTON, GENERIC (per-axis limits), GENERIC_SPRING, MOTOR. empty_name: Name of the new empty that holds the constraint. location: World position of the joint, [x, y, z]. rotation: Joint orientation in radians, [x, y, z]; aims the hinge axis. breaking_threshold: Impulse that snaps the joint; omit for unbreakable. Good for destruction: glue pieces with FIXED and a threshold. disable_collisions: Stop the two bodies colliding with each other. settings: The constraint's own settings, e.g. {"use_limit_ang_z": true, "limit_ang_z_lower": -1.57, "limit_ang_z_upper": 0} for a door, spring_stiffness_x, motor_ang_target_velocity, use_motor_ang.

Returns: Dict with the empty, the type and the two objects.

Input Schema

NameRequiredDescriptionDefault
typeNoFIXED
object1Yes
object2Yes
locationNo
rotationNo
settingsNo
empty_nameNoConstraint
breaking_thresholdNo
disable_collisionsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.0

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does well: it explains that the constraint lives on a new empty, defaults to the midpoint, discloses axis behavior for HINGE/SLIDER/PISTON, and describes breaking thresholds and collision disabling. It still omits details such as cleanup/removal behavior and any performance or permission implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and prerequisite, then structured into an Args section with useful examples. The sentences are information-dense with no obvious filler.

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 complex 9-parameter tool with no annotations, the description covers prerequisites, constraint placement, axis behavior, type-specific semantics, destruction use, settings examples, and return shape. An output schema exists, and the description still gives a brief return summary, so nothing essential is missing.

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 description coverage is 0%, so the description must compensate, and it does: every parameter is explained with added meaning beyond the schema names. In particular, type values are decoded, location and rotation semantics are described, and settings includes concrete examples such as door limits and motor properties.

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?

The description states a specific verb and resource: joining two rigid bodies with a physics constraint. It names the supported constraint types and distinguishes the tool from the prerequisite add_rigid_body by explaining that both objects must already be rigid bodies.

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?

It gives a clear prerequisite: both objects need add_rigid_body first. It also explains which constraint type to use for common goals such as gluing, hinging, sliding, springs, and motors, but it does not explicitly compare this tool with the sibling add_constraint or state when not to use it.

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