Skip to main content
Glama

kernelcad

by com.kernelcad

Export

export

Use this when you need to export geometry to a file. One exporter, selected by target:

  • target:'model' — export the script geometry to one file. Pass { file | code }, a required { output_path }, and { format }. Supported formats: stl (binary STL mesh), step (BREP CAD interchange), dxf (planar laser/waterjet profile from a Region or planar face), 3mf (slicer-friendly mesh with per-part colors), glb (web-viewer / AR with PBR materials), svg-drawing (third-angle engineering-drawing sheet: front/top/left + isometric views, hidden edges dashed, tangent edges thin, overall bounding-box dimensions, title block; assemblies are drawn with inter-part occlusion). Robot descriptions: urdf (tree-topology robot description), srdf (motion-planning semantics layered over the URDF), sdf-gazebo (SDFormat 1.10 with native ball joints, closed loops, and solved per-link poses). urdf and sdf-gazebo also write one meshes/.stl per link next to output_path (reported in mesh_files) — ship the whole directory to the consumer. STL exports run a watertight verify by default; failures return ok: false with export.mesh.not-watertight (open-edge count + up to 5 crack-cluster locations) but the file is still written so the broken mesh can be inspected. Optional { feature_id } selects which feature to export (default: last). Optional { options } carries per-format options bag (see the kernelcad-mcp skill for the per-format keys: dxf layers/tolerance/unit, 3mf printUnit/embedSource, glb axis/draco).

  • target:'part' — export solved-assembly parts as individual binary STL files in their modeled (world-frame) positions. Pass { file | code }, plus { part, output_path } for one part or { output_dir } for all parts (files land at /.stl). A watertight verify runs on every exported mesh by default and fails the call with export.mesh.not-watertight; unknown part names fail with export.part.not-found listing the valid names. Pass { no_verify: true } to skip the watertight gate. All params except target are forwarded verbatim; each target fails closed on its own missing required params.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoInline kernelCAD script source.
fileNoPath to a .kcad.ts script file.
partNotarget:'part' — part name for single-part export, or 'all'.
formatNotarget:'model' — output file format (required for that target).
targetYesWhich exporter to run: 'model' (whole-script geometry to one file) or 'part' (per-part STLs from a solved assembly).
optionsNotarget:'model' — optional per-format options bag. Discriminator options.format must equal top-level format. dxf: { layers?, unit?: "mm"|"cm"|"in", tolerance? }. 3mf: { printUnit?: "mm"|"cm"|"in", embedSource? }. glb: { axis?: "y-up"|"z-up", draco?: false }. svg-drawing: { sheet?: "a4"|"a3", modelName?, date? }.
no_verifyNoSkip the STL watertight verify gate.
feature_idNotarget:'model' — optional FeatureId to export; defaults to last.
output_dirNotarget:'part' — destination directory (all-parts mode); files are <dir>/<part>.stl.
output_pathNoDestination path. target:'model' — the export file (required). target:'part' — single-part .stl path.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
errorNo
formatNo
writtenNotarget:'part' — per-part export records.
byte_countNotarget:'model' — file size in bytes.
mesh_filesNoPer-link mesh files for urdf/sdf-gazebo exports.
diagnosticsNo
output_pathNotarget:'model' — written file path.
feature_countNo

TDQS

A4.9/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond annotations. It discloses default watertight verification, error return patterns (export.mesh.not-watertight, export.part.not-found), and file writing behavior (still written on verification failure). It also explains side effects like writing mesh files for URDF/SDF targets. No contradiction with annotations.

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 detailed but well-structured with clear bullet points for each target and sub-points for formats. It is front-loaded with the main purpose. While long, the complexity of the tool (10 parameters, nested options) justifies the length. Minor denseness prevents a 5.

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 tool's complexity (10 params, nested options, output schema), the description covers all necessary aspects: purpose, usage, parameter semantics, behavioral traits, error conditions, and side effects. It is complete for an AI agent to select and invoke correctly.

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?

With 100% schema coverage, the description still adds significant meaning: it explains conditional parameter requirements based on 'target', describes the per-format options bag in detail, and clarifies the role of 'no_verify'. This goes beyond the schema descriptions.

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 clearly states the tool's purpose: export geometry to a file. It distinguishes two targets ('model' and 'part') with distinct behaviors, providing a specific verb+resource combination. No sibling tool overlaps with this export functionality, making it easy to select.

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?

The description explicitly says 'Use this when you need to export geometry to a file' and provides detailed guidance on when to use each target ('model' vs 'part'). It also explains optional parameters, per-format options, and error conditions, giving clear context for invocation.

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

All kernelcad toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Tools are mostly distinct, with clear descriptions for each. However, there is some potential overlap between inspection tools like 'inspect' and 'mesh_summary', and between rendering tools 'render_preview' and 'get_latest_render', which could cause minor confusion.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern, making it predictable for an agent to infer functionality.

Tool Count2/5

44 tools is significantly higher than the typical well-scoped range of 3-15. While the domain is complex, the count feels excessive and could overwhelm an agent.

Completeness4/5

The tool set covers an extensive range of CAD operations including creation, inspection, rendering, export, and verification. Minor gaps exist, such as direct sketch editing tools, but overall it is comprehensive.

Resources