Skip to main content
Glama

Topology to Solid

topology_to_solid

Turn a topology-optimization density field into a fused FreeCAD solid by thresholding and merging voxels, enabling mass-property and interference validation.

Instructions

Reconstruct a FreeCAD solid from a topology-optimization density field — the modeller-side close of the loop opened by topology_optimize_submit, whose density this consumes. 2-D (nely×nelx grid): thresholds (a cell is solid when density ≥ threshold), run-length-merges each row into solid spans, tiles each span as a cell_mm box extruded thickness_mm in Z (row 0 at the top). 3-D (a nelz×nely×nelx voxel field from the nelz mode): greedy-merges solid voxels into maximal boxes at (i·cx, j·cy, k·cz) — j=0 at the bottom, thickness_mm ignored. Fuses into one static Part::Feature. cell_mm is a scalar or [cx, cy(, cz)] mm; thickness_mm defaults to the smaller cell edge; placement is an optional [x, y, z] mm origin offset; name names the object. Runs synchronously (it builds geometry — no jobs.py poll).

Returns {handle, name, volume (mm³), solid_cells, total_cells, mass_fraction (== solid_cells/total_cells — must be ≤ keep_fraction within one cell), n_solids (disjoint bodies; >1 means a split load path), threshold, nelx, nely, nelz (None for 2-D), bbox_mm}. Gate it with mass_properties (mass ≤ keep_fraction·original) and interference_check against keep-out regions, per SIMULATION_EXAMPLES §5.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
cell_mmNo
densityYes
placementNo
thresholdNo
thickness_mmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations carry only generic false flags, so the description bears the full disclosure burden. It reveals synchronous execution, geometry construction, the exact 2-D and 3-D merging algorithms, defaulting behavior for thickness_mm, and fusion into a single static Part::Feature, which is far beyond what annotations provide.

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

Conciseness5/5

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

The description is long but every sentence earns its place: the first sentence front-loads purpose and upstream dependency, and subsequent sentences pack algorithm, parameter, and return-value details without filler. The structure is appropriately dense for a complex 3-D reconstruction tool.

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?

Given the high algorithmic complexity, lack of an output schema, and minimal annotations, the description is complete. It documents both 2-D and 3-D behaviors, all parameter meanings, the full return object with units and semantic constraints, and downstream validation gates.

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 compensates strongly by explaining density's grid shape, threshold semantics, placement as an origin offset, thickness_mm defaulting, and name. However, it says cell_mm is 'a scalar or [cx, cy(, cz)] mm' while the input schema declares cell_mm as a plain number, a direct contradiction that could mislead an agent.

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 description opens with a specific verb and resource: 'Reconstruct a FreeCAD solid from a topology-optimization density field.' It names the upstream sibling topology_optimize_submit and identifies itself as the modeller-side close of that loop, making it easy for an agent to distinguish from optimization, meshing, and other geometry tools.

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?

It provides clear usage context: consume the density produced by topology_optimize_submit, run synchronously with no jobs.py poll, and gate the result with mass_properties and interference_check per SIMULATION_EXAMPLES §5. It does not explicitly list alternatives or when-not-to-use conditions, but the workflow direction is explicit enough.

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