Skip to main content
Glama

transform_region

Destructive

Move, scale, or rotate selected faces or vertices in world space, with optional falloff to shape nearby geometry, so you can widen, taper, or raise model regions.

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

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

A4.5/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: proportional-editing falloff mechanics with weight curve and falloff_type shaping, the symmetric mirror-twin behavior, the non-mirrored transform caveat, and the returned fields (mirrored_vertices, without_twin, warning). This is exactly the kind of mutation semantics an agent needs on top of destructiveHint=true.

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?

Long but front-loaded: purpose first, then falloff, then symmetric, then where. Given 10 params at 0% schema coverage, most detail earns its place, though the where clause block is dense and could be slightly tighter.

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 10-param mutation tool with no output schema, the description covers purpose, falloff, symmetry, selection filtering, and even names return fields and warning conditions. Complete enough to invoke correctly, with only the rotate_deg semantics left partially implicit.

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?

With 0% schema coverage the description carries the param burden and does well: it defines mode, pivot default, falloff/falloff_type semantics, symmetric axis, and a detailed breakdown of where's keys (normal+angle, x/y/z ranges, box, area, index, empty-match). rotate_deg is only implied by the opening verb, leaving a minor gap.

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?

Opens with a precise verb cluster and resource: 'Move, scale and rotate the vertices of the picked faces ... or the picked vertices ... in world terms', scoping the operation to a region/proportional edit rather than whole objects. This clearly separates it from siblings like transform_objects and deform.

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?

Gives concrete when-to-use context ('widen a head, taper a leg, raise a ridge') and a prerequisite workflow hint ('Look at mesh_info first'). It does not explicitly name alternative sibling tools (e.g. transform_objects vs deform) or exclusions, so it stops short of a full when/when-not statement.

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