OwlCAD

Export STEP (a job)

export_step

Export a SAVED project as STEP (beta) — real B-rep, not a mesh, for CAD interchange. OCCT takes minutes, so this runs as a JOB: call with projectId to get a jobId, then call again with that jobId alone until status is "done", waiting retryAfterMs between polls (polling faster burns your call budget). A poll reports waitingMs; a job still "queued" after a few minutes is stuck, so stop polling and start a new one. Needs a saved project — run save_project first; it cannot export an inline tree. Pro accounts only.

Input Schema

Name	Required	Description
`fit`	No	Beta: fit analytic curved surfaces (cylinders, cones, spheres, tori) instead of flat facets. Default false.
`jobId`	No	A handle from an earlier call. Send it ALONE to poll.
`projectId`	No	The saved project to export. Omit when polling.
`keepFacets`	No	Keep a SET facet count as flat faces: a cylinder, cone, tube or sphere whose side count was set (a hexagonal nut trap, a .scad sphere($fn=8)) exports with the flat faces its STL has, while an automatic count stays a true curved surface. Default true, as in the editor; false exports every round shape curved.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 4, 2026

changedInput schema / properties / fit / description

Previous value: -"Fit analytic surfaces (cylinders, planes) instead of emitting a faceted solid. Default false."New value: +"Beta: fit analytic curved surfaces (cylinders, cones, spheres, tori) instead of flat facets. Default false."

Changed1 schema field changedSep 28, 2026

addedInput schema / properties / keepFacets

Added value: +{
+  "description": "Keep a SET facet count as flat faces: a cylinder, cone, tube or sphere whose side count was set (a hexagonal nut trap, a .scad sphere($fn=8)) exports with the flat faces its STL has, while an automatic count stays a true curved surface. Default true, as in the editor; false exports every round shape curved.",
+  "type": "boolean"
+}

First observedSep 15, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare this is not read-only, not idempotent, and not destructive, but the description adds substantial behavioral context beyond them: OCCT processing takes minutes, the call returns a jobId rather than the finished file, polling must wait retryAfterMs, waitingMs is reported, and Pro accounts are required. It also clarifies that a still-queued job after a few minutes is stuck and should be abandoned rather than polled endlessly.

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 dense but front-loaded with the core purpose and then proceeds through prerequisites, job lifecycle, polling rules, and edge cases. Every sentence carries operationally necessary information, and no space is wasted on restating the name or schema.

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 beta async export tool with no output schema, the definition covers what the agent needs: prerequisite project state, Pro account requirement, job creation and polling mechanics, retry timing, stuck-job detection, and the difference between B-rep and mesh export. Nothing essential is missing.

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 100%, so the baseline is 3. The description adds valuable semantics beyond the schema by explaining the projectId/jobId lifecycle: projectId is used to start the job, jobId is used alone to poll, and the two should not be combined during polling. It does not elaborate fit or keepFacets, but the schema already documents those thoroughly.

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?

States a specific verb and resource: 'Export a SAVED project as STEP (beta) — real B-rep, not a mesh, for CAD interchange.' It distinguishes itself from generic export siblings by naming the format and clarifying it is not a mesh export, so an agent can tell it apart immediately.

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?

Explicitly describes the two-phase async workflow: call with projectId to get a jobId, then poll with jobId alone until status is 'done'. It names the prerequisite (save_project first), states that it cannot export an inline tree, warns about polling budget, and gives a stop condition for stuck queued jobs. This is thorough when/when-not guidance.

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

All OwlCAD tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?