Skip to main content
Glama

remove_physics_asset_constraint

DestructiveIdempotent

Remove a ragdoll constraint (joint) from a UPhysicsAsset by name or index. Deletes an existing joint; absent constraints return already_absent without saving.

Instructions

Remove a ragdoll constraint (joint) from a UPhysicsAsset — the inverse of add_physics_asset_constraint. Resolves the joint by constraint_name (preferred) or constraint_index and deletes it via FPhysicsAssetUtils::DestroyConstraint (the same ConstraintSetup.RemoveAt the PhAT editor runs). Idempotent: an already-absent constraint returns removed:false/already_absent:true with success (no mutation, no save).

Returns: { physics_asset_path: string, constraint_name: string, constraint_index: int, child_bone: string, parent_bone: string, removed: bool, already_absent: bool, constraint_count: int, saved: bool, save_error?: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
constraint_nameNoOptional joint name (JointName) of the constraint to remove; preferred over constraint_index when both are given (see get_physics_asset_info).
constraint_indexNoOptional constraint index to remove (used when constraint_name is absent).
physics_asset_pathYes/Game path to the UPhysicsAsset to remove the constraint from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: annotations only give destructive/idempotent hints, while the description discloses the underlying mechanism (FPhysicsAssetUtils::DestroyConstraint), the exact idempotency contract (removed:false/already_absent:true with success, no mutation, no save), and the return shape. This is exactly the extra context an agent needs for a destructive op.

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?

Front-loads the core action and sibling distinction, then layers mechanism, idempotency, and return shape. The explicit Returns block is verbose but justified since no output schema exists; most sentences earn their place.

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 destructive 3-param tool with no output schema, the description supplies mechanism, idempotency semantics, save behavior, and the full return shape — nothing material is missing for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description restates the constraint_name-over-constraint_index preference that the schema already documents, adding little new parameter semantics.

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?

States a precise verb+resource ('Remove a ragdoll constraint (joint) from a UPhysicsAsset') and distinguishes itself from siblings by naming add_physics_asset_constraint as its inverse. An agent can identify the operation without opening the schema.

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?

Explains the resolution rule (constraint_name preferred over constraint_index) and frames itself as the inverse of add_physics_asset_constraint, giving clear context for use. It does not state explicit when-not-to-use or prerequisites, but the routing logic is well covered.

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