Skip to main content
Glama

transform_region

Move, scale, or rotate selected mesh faces or vertices in world space, with falloff-based proportional editing for targeted 3D shape adjustments.

Instructions

Move, scale and rotate the vertices of the picked faces (mode faces) or the picked vertices (mode vertices) in world terms. pivot defaults to the region centre. falloff > 0 drags the neighbours too, like proportional editing: weights fall from 1 at the region to 0 at falloff metres away, shaped by falloff_type. Use it to widen a head, taper a leg, raise a ridge. symmetric adds the mirror twins of the picked vertices about the centre of the mesh box on that world axis (the answer gives mirrored_vertices and without_twin); the transform itself is not mirrored. Without it the answer has a warning when the mesh is mirror-symmetric and the selection lies on both sides of the plane but is not symmetric. where picks faces (or vertices, edges) by a condition, all given keys must hold: normal ('+Z', '-X' or [x,y,z]) with angle (degrees, default 25); x, y, z ranges [min, max] (null means open) on the world centre; box [[x0,y0,z0],[x1,y1,z1]]; area [min, max]; index [...]. {} or null picks everything. Look at mesh_info first to see where the faces are.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNofaces
moveNo
pivotNo
scaleNo
whereNo
objectYes
falloffNo
symmetricNo
rotate_degNo
falloff_typeNosmooth

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.7/5.0
Behavior4/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. It discloses important behavior: world-space transforms, default pivot at region centre, falloff semantics with weights and falloff_type, symmetric mirror-twin handling, and warning conditions. It still omits some operational context such as mutation/reversibility expectations and object requirements.

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 description is dense but front-loads the core action and uses backticks to structure parameter references. It is appropriately detailed for a complex 10-parameter tool, though some explanatory clauses could be tightened.

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

Completeness4/5

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

For a complex tool with no annotations and no output schema, the description covers most behavior, including falloff, symmetric behavior, where-condition semantics, and some return fields like mirrored_vertices and warning. The missing explanation of the required object parameter and incomplete parameter-name mapping keep it from being fully complete.

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 0%, so the description must compensate. It explains mode, pivot, falloff, falloff_type, symmetric, and the where condition keys, but it does not explicitly document the required object parameter or map move, scale, and rotate_deg to their parameter names.

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?

States a specific verb+resource: move, scale and rotate vertices of picked faces or vertices in world terms. It clearly distinguishes region vertex editing from object-level tools, but does not explicitly differentiate itself from the sibling transform_objects.

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?

Gives use cases (widen a head, taper a leg, raise a ridge) and a prerequisite (look at mesh_info first). It does not name alternatives or state when not to use this tool versus transform_objects, deform, or other transform-related siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.