Skip to main content
Glama
asedias

bl-mcp

by asedias
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

transform_objects

Destructive

Move, rotate, and scale objects with their children, or place multiple objects at specified points in one call, using a pivot and anchor for precise group transforms.

Instructions

Move, turn and scale objects together with their children, or put several objects at their own points in one call: place is {"name": [x, y, z], ...} and anchor is the point of each object's own box that lands there ([0.5, 0.5, 0] is the bottom centre). Order: place, then scale, then rotate, then move. rotate_deg [rx, ry, rz] turns around the world X, then Y, then Z axis. scale is a number or [x, y, z] along the world axes. pivot is a world point for the turn and the scale; the default is the centre of the bounding box of all the objects and their children. Several objects turn as one group. Scaling a turned object by different factors on each axis shears it a little: set the size with set_dimensions first. The answer lists every object after the change. Use it when you know the numbers; to place a part against another use attach or move_to_contact.

Input Schema

NameRequiredDescriptionDefault
moveNo
namesNo
pivotNo
placeNo
scaleNo
anchorNo
rotate_degNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / anchor
      Added value: +{
+  "default": [
+    0.5,
+    0.5,
+    0
+  ],
+  "items": {
+    "type": "number"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / names / anyOf
      Added value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / names / default
      Added value: +null
    • removedInput schema / properties / names / items
      Removed value: -{
-  "type": "string"
-}
    • removedInput schema / properties / names / type
      Removed value: -"array"
    • addedInput schema / properties / place
      Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "items": {
+          "type": "number"
+        },
+        "type": "array"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
    • removedInput schema / required
      Removed value: -[
-  "names"
-]
  2. First observedv0.4.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is covered. The description goes well beyond that by disclosing operation ordering (place, scale, rotate, move), axis order for rotation, the pivot default (bounding-box centre of all objects and children), children being carried along, the shear caveat, and that the response lists every object after the change.

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?

Purpose and the alternative-tool routing are front-loaded, and virtually every sentence carries operational detail (ordering, defaults, axis conventions). It is dense and jargon-heavy with heavy backticking, but not padded; the shear note in particular earns its place as a real failure mode.

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 7-parameter mutation tool with no output schema and no schema descriptions, this description covers the ordering semantics, axis conventions, pivot default, child inheritance, the shear edge case with its mitigation, and the return shape ('lists every object after the change'). An agent has enough to invoke it correctly without guessing.

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 coverage is 0%, so the description carries the full burden and largely succeeds: it defines the `place` mapping format, anchor semantics and its [0.5, 0.5, 0] default, rotate_deg's [rx, ry, rz] world-axis order, and scale as number-or-triple along world axes. `move` is only implied as translation and `names` is never explained, leaving two of seven parameters under-specified.

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 opening clause names a specific verb set (move, turn, scale) and resource (objects with their children), and the closing sentence explicitly routes agents away from this tool when the goal is contact-based placement, naming attach and move_to_contact as the alternatives.

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

Usage Guidelines5/5

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

It states both sides of the routing decision: 'Use it when you know the numbers; to place a part against another use attach or move_to_contact.' It also gives a precondition for a hard case (set_dimensions first before non-uniform scaling of a rotated object). Nothing is left to inference.

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