Skip to main content
Glama

Check printability

print_check
Read-onlyIdempotent

Checks a finished STL or run folder for printability: mesh integrity, bed fit, overhangs, supports, wall thickness, and plate contact, reporting pass/fail/unknown against limits.

Instructions

Check a finished part for printing. Geometry only: no solve, no run. It gives the same report as topopt printcheck.

path: an STL file or a run folder (it has result/final.stl); relative paths start at the work folder. With no path, the last run is used. It works on any STL (final.stl, a nominal.stl, an edited.stl): no metrics.json and no YAML are needed. About 2 to 5 s for an 85,000-triangle part. yaml_path: a problem YAML whose print block gives the settings and limits. A run folder already has the print block of its run. print_settings: a dict with keys of the print block, for example {"min_wall_mm": 1.2, "bed_mm": [250, 210]}; it wins over the YAML. resolution_mm: the size of the smallest member that the mesh holds: the voxel size (a run folder gives it), or 0 for exact CAD. The default is the voxel size of the run, else the median mesh edge. strict: opt in to the gate. Without it the tool only reports. gate: with strict, state is fail only when a check that has a limit fails (unknown never sets it); exit_code is then 4 and override names the way on. No run stops on it. On an input that cannot be read: {"ok": false, "error": ...}. A failed check is data, not an error. A print pass is not a structural pass. A finished run already has this report as result/print_check.json (run_result shows its counts): call this tool again for other limits or another direction. Each check has id, state (pass, fail or unknown), reason, value, limit (value, key and source: run.json, yaml, option, profile:, assumed or none) and method. Checks: mesh_closed (the STL as a float32 file: open and non-manifold edges, winding, volume), bodies, closed_voids (count and volume), bed_fit, overhang, support_volume, plate_contact, wall_thickness. The limits are print-block keys: bed_mm, max_bodies, min_wall_mm, min_wall_area_pct, max_closed_void_mm3, max_overhang_area_mm2, max_support_volume_mm3, min_plate_contact_mm2, and the V2 keys build_direction, printer_type and self_supporting_angle_deg. printer_model (a printer of find_printer) gives the bed, the type (source profile:) and the build height: bed_fit then also compares the part height with it. A check with no limit is unknown and its value is a fact. The thickness is an estimate: by the rule of this check it passes only if the limit is at least 3 x the resolution; a thin wall that is measured fails at any resolution. When it is unknown only for that rule, value.pass_needs gives the resolution that a pass needs (resolution_mm_at_most, and voxel_count_factor for a run folder: an estimate of the voxels of that grid against this one). Also: summary, settings (with from: where each source came from), input (path, sha256), timing_s, definitions. partial, coverage: partial is true when a check that is asked for stopped with an error (its record has state unknown and error; the other checks go on) or has a limit and could not decide. coverage has ran, failed (name, reason) and not_run (name, reason, asked); a check that is not asked for (the support volume of a powder-bed printer) does not make it partial.

Input Schema

NameRequiredDescriptionDefault
pathNo
strictNo
yaml_pathNo
resolution_mmNo
print_settingsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent, but the description adds real behavioral context they cannot: strict-gate semantics (exit_code 4, override path, 'No run stops on it'), the 'failed check is data, not an error' contract, the {

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 is front-loaded and each parameter gets its own block, so it scans well for its size. It is long and dense with backticked jargon, and the check/coverage documentation at the end runs together, but with no output schema most of that is load-bearing rather than padding.

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?

There is no output schema, so the description documents the return payload itself: per-check fields (id, state, reason, value, limit with source, method), the nine check names, the summary/settings/input/timing_s/definitions block, and the partial/coverage failure model. Nothing material is left for the agent to discover empirically.

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 description coverage is 0%, so the description must carry all five parameters, and it does: path resolution rules and defaults, print_settings example dict with concrete keys, resolution_mm meaning (voxel size vs 0 for exact CAD) plus its default, and strict's opt-in semantics. The YAML/settings/option precedence order is exactly the detail an agent needs to call this correctly.

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 specific verb and resource ('Check a finished part for printing') plus an explicit scope boundary ('Geometry only: no solve, no run') and an equivalence anchor ('same report as `topopt printcheck`'). That cleanly separates it from run_topopt, run_result and verify_run in the sibling list.

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?

States when the tool is not needed ('A finished run already has this report as result/print_check.json (run_result shows its counts)') and when to re-invoke it ('call this tool again for other limits or another direction'). It also resolves the input-precedence questions an agent would otherwise guess at (print_settings wins over YAML; a run folder supplies the print block).

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