Skip to main content
Glama

Build regions from a spec

build_regions
DestructiveIdempotent

Build region STLs and a problem YAML from a part specification, defining design spaces, fixed regions, loads, keep-out zones, and solid bodies for topology optimization.

Instructions

Build region STLs and a problem YAML from a part spec given as data.

Use it when the user describes a part in words. Define the design space, fixed regions, loads (force vectors in N), keep-out regions (if any) and solid bodies (solid, forced solid). It already returns check and warnings. Call check_problem only after you edit the YAML, or for your own STLs. Next: state your assumptions, then run_topopt. If the user gave no load (no object, no mass and no force), ask before the run. A guard stop names an override: read the memory estimate against the RAM (a run above it can freeze the machine), raise the guard in the spec or take a larger voxel, and report what, why and the price. Writes /runs//. Reply keys: resource topopt://replies/build_regions (the meaning of each key). Use yaml_rel with run_topopt. On a wrong spec: {"ok": false, "error": one line that names the key path}. ok is false also when the builder fails (builder_ok false): problems gives the builder errors, and the files stay. name: folder and file name; default is spec["name"]. spec: a dict (or YAML text) with the schema of the part-to-topopt skill (spec.yaml): regions (design, fixed, load, solid, keep_out; primitives box, cylinder, sphere, capsule, bowl, prism, stl and screw_ring (see find_features), subtract), load_cases, material (E, nu, density or filament), settings (voxel_size may be "auto"; optional min_member_mm, filter_solid_neighbours, stop_rules (as in the YAML: a mapping turns the stop rules on, and time_budget_s, the user's own time budget, ends the run at the first pass after it; enabled: false keeps the rules off; the check warns when the estimate is above the budget) and perimeter_max_mm2: a bound on the surface area of the part in mm2). Units mm, N, MPa. settings.volume_fraction (default 0.25) is the mean density of the FREE design voxels; the fixed, load and solid voxels are solid on top. The YAML keeps your value. A mass in grams that the user asks for goes to settings.target_mass_g in place of volume_fraction (one of the two keys; both is an error): the engine derives the fraction from the grid. The report and derived.volume give the free and the forced-solid voxels, the target volume in mm3 and the target mass in g (the same numbers as check_problem). Loads: a force entry can also have moment in N mm and at in mm, and a case can have pressures of {region, value_mpa}. A fixed_axes mapping (fixed name -> axes) makes a roller of a fixed region. A springs list of {region, stiffness: [kx, ky, kz]} (N/mm, total; or stiffness_per_area) makes an elastic support on a load region; fixed may then be empty. A joints list of {region, to: [x, y, z], section: {kind: round, d: ..}} (mm; kinds round, tube, rect, props) bonds the faces of a load region to a rigid body and joins it with a beam to the fixed point to; fixed may then be empty. A flat face of a region whose plane is not on a voxel face (a voxel belongs to a region when its centre is inside) moves to the nearest voxel face. When such planes change the part, the report has ONE note: line (also in warnings) with the voxel size, the grid origin, an item for each plane (the region, the plane, larger or smaller than your shape) and the options. check.region_planes has all planes, with offsets in mm and voxels, and changes_part (false when the layer is under a region of higher priority or outside the part). Items in one region join (union). Optional spec key mirror: a list of up to 3 axis-aligned planes with distinct axes, each {normal: x|y|z, at_mm: }, align: auto|face|centre optional. The tools return facts about it (parity, orphans, load asymmetry).

Input Schema

NameRequiredDescriptionDefault
nameNo
specYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the annotations: writes to <work folder>/runs/<name>/, returns check and warnings itself, leaves files on builder failure with problems listing the errors, error shape is {ok:false, error} naming the key path, and a guard stop can freeze the machine if the memory estimate exceeds RAM. The idempotent/destructive hints are consistent with a spec-to-files build.

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

Conciseness3/5

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

Purpose and usage are front-loaded, but the body is a dense wall of run-on sentences mixing tool behavior with exhaustive spec-schema detail (voxel-plane notes, mirror parity, spring stiffness units). Much of that content earns its place given 0% schema coverage, yet its organization makes it hard to scan.

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 spec-driven builder with no output schema, the description covers inputs, side effects, result keys, error shapes, guard-stop handling, and where further detail lives (topopt://replies/build_regions, spec.yaml). Nothing an agent needs in order to call it correctly appears to be 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 coverage is 0%, so the description carries the full burden and does: it documents the `name` default (spec["name"]) and expands `spec` in depth — regions, primitives, load_cases, material, settings, units (mm, N, MPa), volume_fraction vs target_mass_g mutual exclusion, mirror/springs/joints/fixed_axes. An agent could construct a valid spec from this text alone.

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 sentence states a specific verb and two concrete artifacts ('Build region STLs and a problem YAML from a part spec given as data'), and the second sentence pins down the triggering condition (user describes a part in words). Named siblings (check_problem, run_topopt, find_features) make its position in the pipeline unambiguous.

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?

Explicit routing: use it when the part is described in words, call check_problem only after editing the YAML or for the agent's own STLs, then state assumptions and go to run_topopt. It also gives a decision rule for missing load data (ask before the run) and a recovery procedure for a guard stop.

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