Skip to main content
Glama
RobertCoop

OpenSCAD MCP Server

by RobertCoop

validate

Verifies OpenSCAD models for syntax errors, geometry issues, predicates, includes, and printability, returning findings and fixes.

Instructions

Check a model. "valid" is false whenever an ERROR was reported, whatever OpenSCAD's exit code was. mode: "syntax": parse and evaluate without geometry (fast): errors, warnings, echo_output, hints, unresolved_includes with locations. "geometry": export the mesh and report findings: not watertight, non-manifold, several solids, cavities, empty; with the numbers. "predicates": predicates=["W > 10", ...] evaluated in the model's own scope; each must be true. sweep={variable, values:[..]} re-runs them per value and reports the first failure and the crossing. "includes": every include/use/import/surface reference with its resolved path, plus the BOSL2 lint: a module from a use<>d file placed by attach()/position() is silently put at CENTER; findings carry a fix plan, applied to the file when autofix=true and safe. "printability": rules from reference(topic=dfm) over measure(mode=printability) facts in orientation=; profile= {overhang_deg, nozzle_mm, max_unsupported_reach_mm, min_wall_mm} overrides thresholds. Findings carry magnitude and location.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNosyntax
sweepNo
autofixNo
profileNo
scad_fileNo
variablesNo
predicatesNo
orientationNo
scad_contentNo
include_pathsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.1

TDQS

A4.3/5.0
Behavior4/5

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

The description discloses important behavioral details beyond the schema: 'valid' is false whenever an ERROR was reported regardless of OpenSCAD exit code; syntax mode returns errors/warnings/echo_output/hints/unresolved_includes with locations; geometry mode reports specific mesh findings with numbers; predicates mode re-runs per sweep value and reports first failure and crossing; includes mode includes a BOSL2 lint with autofix behavior. This is substantial behavioral context, though it does not cover all edge cases (e.g., exact output shape, error handling for invalid mode values).

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 and structured as a mode-by-mode list, which is appropriate for a multi-mode tool. It front-loads the core behavior ('valid' is false on ERROR) and then each mode gets a compact explanation. It is longer than a typical description, but the complexity of the tool justifies the length; every sentence adds information.

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?

The description covers the main modes, their outputs, and key parameters, and an output schema exists to define return values. It does not explicitly state prerequisites (e.g., whether scad_file or scad_content is required), nor does it detail all parameter interactions (e.g., how variables interact with predicates). However, for a tool with 10 optional parameters and an output schema, the description is largely complete.

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?

Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It explains mode values, sweep, predicates, autofix, profile, orientation, and measure(mode=printability) facts. It does not explicitly explain scad_file, scad_content, variables, or include_paths, but the mode descriptions imply their roles (e.g., includes mode resolves include/use/import/surface references). Given 10 parameters and 0% schema coverage, the description compensates well but not completely.

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 clear verb-resource pair ('Check a model') and then enumerates five distinct modes (syntax, geometry, predicates, includes, printability), each with a specific purpose. This distinguishes validate from siblings like check_openscad, scad_eval, export_model, and measure by showing it is a multi-mode model checker.

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?

The description explains what each mode does and when it would be relevant (e.g., 'syntax' for fast parse/geometry-free checks, 'geometry' for mesh export findings, 'printability' for DFM rules). It does not explicitly name sibling tools as alternatives or state when not to use validate, but the mode breakdown gives clear context for selecting the right mode.

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