Parametric 3D CAD for AI agents. Claude Code, Cursor or any MCP client can build and edit real OwlCAD projects: primitives, booleans, and generators for gears, threads and Gridfinity. Check a part for printability and interference, then export STL, 3MF, OBJ or STEP. Output is an editable model with named millimetre dimensions, not a mesh, so you can open it in the browser and change any value afterwards. Sign in with OAuth or an access token. Requires OwlCAD Pro.
Scored across 29 tools
Tools have distinct roles, with analysis (evaluate, print_check, measure, check_interference), export variants, and editing tools well separated. The only mild overlaps are edit_project vs edit_nodes and save_project vs update_project, but descriptions explicitly clarify saved vs unsaved and new-project vs replace-existing usage.
All names use snake_case with a predictable verb_noun construction (list_projects, get_project, import_model, edit_project). A few noun-only names like job_status and print_check, and bare verbs like evaluate/export/render, are minor deviations but remain readable and consistent overall.
29 tools is heavy for an MCP server; while the CAD domain is broad, several functions (edit_project/edit_nodes, multiple export and project-write paths) could be consolidated. It remains usable, but the surface is on the high side and risks overwhelming selection.
The surface covers the full CAD lifecycle: import, inspect, edit, analyze, render, repair, split, export, and project/folder/share management. Minor gaps such as duplicating one's own project or renaming a project can be worked around with existing read/save flows.
Ask, in plain language, how to achieve something in OwlCAD and get a prose answer grounded ONLY in the product documentation, with the ids of the help articles it drew on. Use this when you need to know which tool or parameter does a thing — "how do I make a hole an M3 bolt passes through", "what does the clearance modifier do" — rather than guessing at a tool call. It answers from the docs and says so when they do not cover something, so an empty answer is information, not a failure. It changes NOTHING: no project is read or written. Requires a Pro plan and the ask scope, and it draws on the SAME small daily allowance as the in-app assistant, so prefer the schema resources for anything they already answer.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Answer language: en, es, de or fr. Defaults to en. | |
| history | No | Earlier questions in this conversation, oldest first, for follow-ups. Max 6 are used. | |
| question | Yes | What you want to do, in plain language. Max 500 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes further: 'It changes NOTHING: no project is read or written.' It also explains that an empty answer is information, not failure, and that the tool draws on the same daily allowance as the in-app assistant. This adds real behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet dense: it front-loads the core purpose, then adds usage guidance, behavioral guarantees, auth requirements, and quota context. Every sentence earns its place and there is no filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only Q&A tool with three well-documented parameters and no output schema, the description covers everything an agent needs: what it does, what it returns, when to use it, what it does not do, auth scope, quota behavior, and how to interpret empty answers. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents question, locale, and history fully. The description reinforces that the question should be in plain language and max 500 characters, but it does not add meaning beyond the schema for any specific parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Ask'), resource ('how to achieve something in OwlCAD'), and a clear outcome: a prose answer grounded only in product documentation with cited help article IDs. This clearly distinguishes ask_help from sibling tools that actually perform CAD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool — when you need to know which tool or parameter does a thing 'rather than guessing at a tool call' — and gives an exclusion: prefer schema resources for anything they already answer. It also discloses the shared daily allowance, which affects cost-aware selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find which top-level parts physically overlap, and by how much volume. This is the assembly check you cannot do by reasoning about a tree OR by looking at a render — an interference is usually hidden inside the model. Run it on anything with more than one part that is meant to fit together.
| Name | Required | Description | Default |
|---|---|---|---|
| scad | No | OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset(). | |
| nodes | No | Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong. | |
| projectId | No | Id of one of your saved projects, as an alternative to `nodes`/`scad` (supply exactly one). | |
| smoothness | No | Curve quality for shapes that left their segment count automatic. Defaults to "standard", which is the editor default — pass "high" to match a project authored at high smoothness, "draft" for a cheaper check. | |
| minVolumeMm3 | No | Ignore overlaps smaller than this (default 0.001). Parts that merely share a face graze each other numerically; this is what stops that being reported as a collision. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds domain context ('an interference is usually hidden inside the model') but no tool behavior such as cost, latency, or result format. With annotations carrying the burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, zero waste, with the core purpose front-loaded before the justification and the usage cue. Nothing is repeated or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only check with 100% schema coverage, the main remaining burden is what comes back, since there is no output schema. The description conveys the shape of the result (which parts overlap and by how much volume), which is enough to call it correctly, though return format details are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters in detail (including minVolumeMm3's grazing rationale and smoothness defaults). The description's 'by how much volume' loosely maps to minVolumeMm3 but adds no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find which top-level parts physically overlap, and by how much volume') and goes further to distinguish the operation from what sibling capabilities can achieve ('cannot do by reasoning about a tree OR by looking at a render'). An agent can tell this apart from render/measure/evaluate without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering condition: 'Run it on anything with more than one part that is meant to fit together.' It also implicitly rules out tree reasoning and rendering as substitutes. It stops short of naming the adjacent sibling tools (measure, print_check) as alternatives, so it is strong but not fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a URL to PUT a local file to, so import_model and import_2d can take it WITHOUT the bytes passing through your context — base64 costs roughly 380,000 tokens per megabyte and most clients cannot produce it at all. PUT the file to uploadUrl with the headers given, then call the importer with ticketId. If you cannot PUT, give the person handoffUrl and they upload it in their browser; poll the importer until it stops answering awaiting_upload. Note the TWO expiries: uploadUrl dies in minutes, the ticket lasts a day — pass ticketId back here for a fresh URL rather than starting over.
| Name | Required | Description | Default |
|---|---|---|---|
| bytes | No | Size of the file you are about to send. Refused now if over the limit. | |
| format | No | Required unless refreshing a ticket. | |
| ticketId | No | An unfilled ticket whose uploadUrl expired. Re-issues the URL only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false, the description carries the full burden. It discloses behavioral traits beyond the schema: the two expiries (uploadUrl minutes, ticket a day), the need to pass ticketId back for a fresh URL, the polling requirement, and the token-cost rationale. It accurately conveys that this is a stateful, multi-step operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense, with the purpose and token warning front-loaded, followed by a logical workflow and expiry notes. Every sentence adds actionable detail—no filler. It is appropriately sized for the complexity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey what the tool returns. It mentions uploadUrl, headers, ticketId, and handoffUrl, and explains the complete flow including fallback and polling. An agent has all the information needed to call and use the tool correctly without external assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds workflow context that the schema lacks: the relationship between format and ticketId (format required unless refreshing), the purpose of bytes (size check), and how ticketId re-issues only the URL. This enhances parameter understanding beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get a URL to PUT a local file to') and resource (an upload URL for import tools), and explicitly names the sibling tools import_model and import_2d, distinguishing its purpose. It also explains the context of avoiding base64 token costs, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear when-to-use scenario (uploading a file for import) and a detailed workflow: PUT to uploadUrl, call importer with ticketId, fallback to handoffUrl if PUT fails, and poll the importer. It also explains when to use the ticketId refresh path, effectively covering alternatives and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete one of your projects and its geometry. Irreversible — there is no trash. Deleting a project you did not create is not possible.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The project to delete permanently — one you created. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint/readOnlyHint annotations, the description discloses what gets destroyed (project plus geometry), that deletion is permanent, that there is no trash/recovery, and that ownership is required. This is exactly the behavioral context that matters for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-load the action and consequence with no filler. Every sentence adds information relevant to invoking the tool safely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool, the combination of schema, annotations, and description fully covers what the tool does, what it requires, what is destroyed, and the irreversibility. No output schema is needed for this action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the projectId property description already states it must be a project the caller created. The tool description reinforces ownership but does not add syntax, format, or meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('permanently delete'), resource ('one of your projects'), and scope ('and its geometry'), and adds the unique consequence of being irreversible with no trash. This separates it from update/edit/remix siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the tool is for deleting a project the caller created, and explicitly says deleting a project the caller did not create is not possible. It does not name alternative tools for non-owned or reversible actions, but the ownership condition is a clear usage constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply edit ops to a node tree you pass IN, and get the edited tree back. Nothing is saved and no project is touched — this is the unsaved counterpart to edit_project. Use it to change a model you are still working on without re-sending the whole tree every time: add a node, cut a hole, group parts, wrap a modifier, then feed the result straight to evaluate, print_check or export. Target nodes by their id; a node you send keeps the id you gave it, and one you omit an id for gets one back in the result, so a later call can name it. Unlike edit_project this is FORGIVING: an op that cannot be applied is skipped and reported in skipped rather than failing the whole call, because nothing here is written and a nearly-right tree beats none; what your nodes lost the same way is in treeWarnings. Same ops as edit_project — read owlcad://schema/edit-ops for what each op requires (this tool’s ops carry no schema of their own), and owlcad://schema/primitives for the node vocabulary an addNode carries.
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | Edits to apply in order, each against the result of the last. Up to 40. Same shape as edit_project's. | |
| nodes | Yes | Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantive context beyond that: nothing is persisted, no project is touched, failed ops are skipped and surfaced in `skipped` rather than aborting, and node-loss is reported in `treeWarnings`. The id-retention rule for later calls is also disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core contract and the edit_project contrast, and every clause carries information. It is dense and long, with some clauses packed tightly, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by explaining the return (edited tree, `skipped`, `treeWarnings`) and by routing the agent to the two resources that define the op and node vocabularies. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning: `id` targeting and id retention/assignment, that `ref` is a label rather than an id, and that `ops` carry no schema of their own and must be read from a resource. It stops short of describing the op vocabulary itself, deferring that to the resource.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource+contract: 'Apply edit ops to a node tree you pass IN, and get the edited tree back.' It explicitly names the sibling it is the counterpart to (edit_project) and the difference (unsaved, in-memory), so an agent can distinguish it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use it ('change a model you are still working on without re-sending the whole tree') and names downstream alternatives it feeds (evaluate, print_check, export), plus the contrast with edit_project for the saved case. Conditions that select this tool over siblings are explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a TARGETED change to one of your projects — change a parameter, move a node, add or remove one, group nodes into a boolean, create or set a variable, switch configuration. Prefer this over update_project when you are changing an existing model: it needs only the ids you are touching, not the whole tree, and it does not strand mates the way a wholesale replacement does. Read with get_project authored: true first — those are the ids this accepts. Every op must apply or the whole call is refused and nothing is written. It can also restructure: dissolve a boolean, unwrap a modifier, or turn a selection into a reusable component you place again with addInstance — which is how you build an assembly without paying for every copy against the node cap. owlcad://schema/edit-ops lists what every op requires; the schema below is a flat bag of every field any op takes.
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | Edits to apply in order, each against the result of the last. Up to 40. | |
| name | No | Rename the project at the same time (optional). | |
| version | Yes | The `version` get_project reported. A mismatch means someone else changed it — re-read and retry. | |
| projectId | Yes | The project to edit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark destructiveHint=true, and the description adds meaningful behavioral detail beyond that: the call is atomic ('Every op must apply or the whole call is refused and nothing is written'), edits are targeted and do not strand mates, and the tool can restructure the tree. It does not address auth requirements or rate limits, but the atomicity and side-effect framing go beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the purpose and the most important usage guidance (prefer over update_project, prerequisite, atomicity) before secondary restructure capabilities and the external reference. Every sentence carries operational meaning with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very complex (25 op types, no output schema), but the description compensates with key call semantics: ordered ops, atomicity, authored-id prerequisite, and a pointer to the external edit-ops schema for per-op requirements. It does not describe the success/return payload or error variants, and does not clarify the relationship with edit_nodes, so it is strong but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 top-level description only adds a pointer to owlcad://schema/edit-ops and the caveat that the schema is a flat bag of every field any op takes. It does not explain individual parameter meanings beyond what the schema already provides, which is acceptable but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Make a TARGETED change to one of your projects') and lists concrete operations like changing a parameter, moving a node, grouping nodes, and setting variables. It explicitly contrasts itself with update_project, but does not distinguish itself from the similarly named sibling edit_nodes, which by name and the node-focused operation list appears to overlap. This is clear but not fully differentiated across all relevant siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to prefer this tool over update_project ('when you are changing an existing model', because it needs only touched ids and avoids stranding mates) and gives a required prerequisite ('Read with get_project `authored: true` first'). It does not, however, say when edit_nodes would be the better alternative, so the guidance is strong but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a model through the real CSG kernel and report whether it BUILDS: watertight, triangle count, bounding size in mm. Call this before exporting — an empty result usually means boolean operands did not overlap the way you expected. Its warning is only a bounding-box sanity check (a sub-mm feature, or bigger than a typical bed); it does NOT look at overhangs or wall thickness, so a clean evaluate does not mean the part prints — run print_check for that, and measure for material. A node or op in your nodes that could not be built as sent is dropped or changed and named in treeWarnings — fix it and call again.
| Name | Required | Description | Default |
|---|---|---|---|
| scad | No | OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset(). | |
| nodes | No | Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong. | |
| projectId | No | Id of one of your saved projects, as an alternative to `nodes`/`scad` (supply exactly one). | |
| smoothness | No | Curve quality for shapes that left their segment count automatic. Defaults to "standard", which is the editor default — pass "high" to match a project authored at high smoothness, "draft" for a cheaper check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive, but the description adds substantial behavioral context beyond them: the `warning` is only a bounding-box sanity check and does not assess overhangs or wall thickness, and nodes that fail to build are dropped/changed and named in `treeWarnings` with a fix-and-retry loop. This is exactly the extra context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and result fields, then limitations, then the treeWarnings retry note. Dense and mostly efficient, though it is a long run of clauses where a couple could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the full burden and does so: it enumerates the return fields (watertight, triangle count, bounding size), the `warning` semantics, and `treeWarnings` behavior. Nothing an agent needs to call or interpret this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents scad/nodes/projectId/smoothness thoroughly. The description adds no further parameter syntax or semantics, so the baseline 3 is appropriate — the schema does the heavy lifting here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (run a model through the CSG kernel) and names the concrete outputs — watertight, triangle count, bounding size in mm. It also clearly distinguishes itself from siblings by naming print_check and measure, so an agent can route without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to call it ("before exporting"), how to interpret an empty result (boolean operands didn't overlap), and where to go for adjacent concerns (print_check for printability, measure for material). This is full when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a model and return it as base64 bytes in STL, 3MF or OBJ. 3MF comes back CARVED — one object per top-level part, named from the scene tree and carrying its colour, so a slicer can arrange and recolour them separately; the result lists the names in objects. STL is one fused mesh (the format has no object concept). For STEP use export_step — it is B-rep, takes minutes, and runs as a job.
| Name | Required | Description | Default |
|---|---|---|---|
| scad | No | OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset(). | |
| nodes | No | Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong. | |
| format | No | File format. 3MF keeps each top-level part as its own named, coloured object; STL is one fused mesh. | stl |
| deliver | No | How to return the bytes. `inline` (default) is base64 in the result, capped because it lands in your context. `url` writes the file to your account and returns a link good for 24 h instead, which lifts those caps — use it for anything large, or to hand a person a file. | inline |
| projectId | No | Id of one of your saved projects, as an alternative to `nodes`/`scad` (supply exactly one). | |
| smoothness | No | Curve quality for shapes that left their segment count automatic. Defaults to "standard", which is the editor default — pass "high" to match a project authored at high smoothness, "draft" for a cheaper check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false / destructive=false / idempotent=false, so the description carries real weight and delivers: inline base64 is context-capped, url writes a file to the account with a 24h link, and 3MF comes back carved into per-part named, coloured objects listed in `objects`. That is substantive behavior beyond the annotation set, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four front-loaded sentences: purpose, then 3MF/STL semantics, then sibling routing. Each earns its place, though the format explanation partly duplicates the schema's own `format` description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema the description must carry return semantics, and it does explain bytes/base64, the `objects` name list, and the url link lifetime. The full result envelope is only partially sketched, but nothing needed to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 mostly restates the `format` and `deliver` semantics already spelled out in the schema; its only net-new parameter-adjacent detail is that the result lists part names in `objects`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — evaluate a model and return mesh bytes in STL/3MF/OBJ — and explicitly separates itself from `export_step` (B-rep, minutes, job) and implicitly from `export_2d`. An agent can route without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names one concrete alternative with the condition that selects it: "For STEP use `export_step` — it is B-rep, takes minutes, and runs as a job." The `deliver` guidance also frames when to choose url (large files, handing a person a file). It does not distinguish this from sibling `evaluate`, `render`, or `export_2d`, so it stops short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flatten the model to 2D as DXF or SVG, for a laser, vinyl cutter or CNC. The default "silhouette" projects it onto the view plane; "section" cuts through it — how to check an internal wall or bore no render shows.
| Name | Required | Description | Default |
|---|---|---|---|
| z | No | Section position, mm, on the view axis (z, y or x). | |
| cut | No | SVG: hairline laser cut lines, no fill. | |
| arcs | No | Default true: facets become true circles and arcs. | |
| mode | No | Default "silhouette" (footprint). "section" needs `z`. | |
| scad | No | OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset(). | |
| view | No | Default "top"; "front" from −y, "right" from +x. | |
| nodes | No | Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong. | |
| format | No | DXF for CAD/CAM and lasers, SVG for cutters and the web. | dxf |
| deliver | No | How to return the bytes. `inline` (default) is base64 in the result, capped because it lands in your context. `url` writes the file to your account and returns a link good for 24 h instead, which lifts those caps — use it for anything large, or to hand a person a file. | inline |
| projectId | No | Id of one of your saved projects, as an alternative to `nodes`/`scad` (supply exactly one). | |
| dxfVersion | No | DXF flavour (default R2000; use R12 for older controllers). | |
| smoothness | No | Curve quality for shapes that left their segment count automatic. Defaults to "standard", which is the editor default — pass "high" to match a project authored at high smoothness, "draft" for a cheaper check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=false), and the description adds useful behavioral semantics about silhouette vs section geometry. It does not state side effects such as file creation or the fact that deliver=url writes to the account, which matters for a tool flagged non-read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core action front-loaded ahead of the mode distinction. The trailing clause about internal walls/bore is somewhat awkwardly worded and slightly obscures its own point, costing a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool the description correctly focuses on purpose and mode semantics while the fully-covered schema handles parameters and the three mutually exclusive input sources (nodes/scad/projectId). No output schema exists, so return values need not be described; remaining gaps are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every one of the 12 parameters carries its own prose, so the schema does the heavy lifting. The description reinforces mode semantics but adds little syntax or default information not already in the schema, matching the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Flatten the model to 2D as DXF or SVG') and names the two generation modes and their meaning. It never names a sibling (export, export_step, import_2d), so the agent must infer the 2D vs 3D split from context, keeping this short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete applicable contexts (laser, vinyl cutter, CNC) and routes between the two modes: default silhouette for footprint, section 'how to check an internal wall or bore no render shows'. It offers no explicit when-not or named alternative tool, so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (which only mark it non-read-only, non-idempotent, non-destructive) by disclosing the multi-minute OCCT runtime, the job/polling model, the retryAfterMs backoff requirement and the call-budget cost of over-polling, the waitingMs poll field, and the stuck-job failure mode. It does not describe the success artifact (file handle/download) beyond the done status, keeping it at 4 rather than 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense and front-loaded with the core action and output format first, then the job mechanics. Every sentence carries information, though the parenthetical asides (call budget, stuck jobs) make it longer than strictly needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description covers the returned fields (jobId, status, waitingMs), the terminal condition (status 'done'), and the failure condition (stuck 'queued'). Combined with the auth/plan constraint and prerequisite, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, but the description adds meaning the schema lacks: projectId is for starting a job and yields a jobId, jobId must be sent alone to poll, and retryAfterMs governs poll spacing. That call-pattern semantics is genuinely additive over the per-parameter schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Export), resource (a SAVED project), and output format (STEP, real B-rep not a mesh), plus the interchange use case. Clearly distinguishable from the sibling export/export_2d tools by naming STEP and the CAD-interchange intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it (saved project only, pro accounts only), the prerequisite alternative (run save_project first; cannot export an inline tree), and the exact two-phase calling procedure with projectId then jobId. It also tells the agent when to stop (a job stuck 'queued' after a few minutes) and to start a new one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load one of the authenticated account’s projects and list its nodes with their current parameters — for inspecting or describing an existing model. Reports any variables, components, configurations and mates the project carries beyond its nodes. Pass authored: true before you intend to CHANGE it.
| Name | Required | Description | Default |
|---|---|---|---|
| authored | No | Return the tree as STORED, with the ids the document really carries (default false, which returns the resolved scene that evaluate/render/export act on). Use true whenever you plan to write back: the resolved form has instances expanded into copies with synthesized ids, the mate solve folded into transforms, and a suppressed configuration’s bodies missing — so writing it back flattens all three. | |
| projectId | Yes | The project to load — one of yours; see `list_projects`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral detail beyond that: it explains the difference between the resolved scene (what evaluate/render/export act on) and the stored tree, and warns that writing back the resolved form flattens instances, mates, and suppressed bodies. It also notes that the tool reports variables, components, configurations, and mates. No contradiction with annotations; the description enriches the behavioral model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact three-sentence block that front-loads the primary purpose ('Load one of the authenticated account's projects and list its nodes') and then adds the key behavioral nuance about the authored flag. Every sentence serves a purpose, and it avoids redundancy with the schema. It is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the schema covers parameters fully, and there is no output schema. The description explains what the tool returns (nodes, parameters, variables, components, configurations, mates) and the critical resolved-vs-stored distinction. It does not describe output format or pagination, but for a read tool with clear annotations, this is sufficient. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces the 'authored' parameter's importance but does not add new semantic information beyond the schema's detailed explanation. The projectId parameter is referenced in the description ('one of the authenticated account's projects') but the schema already covers it. This meets the baseline for high coverage without adding substantial extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a project and lists its nodes with parameters, and frames it as for inspecting or describing an existing model. It identifies the resource (project) and the action (load/list), but does not explicitly name a sibling tool to differentiate from, though the read-only intent is implicit. This is clear and specific, but not maximally distinct from other read-oriented siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'for inspecting or describing an existing model' and advises passing 'authored: true' before intending to change the project. This tells the agent when to use the tool and how to configure it for a follow-up write. However, it does not name alternative tools (e.g., list_projects for enumerating, edit_nodes for modifications) or explicitly state when not to use this tool, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a DXF as a new project, extruded into solid geometry. Unlike a mesh import this stays PARAMETRIC — every closed outline becomes an extrude node whose profile and height you can then edit, so a drawing someone sent you becomes a model you can change. The response reports what the file declared its units to be, and names any entity types it contains that were not read.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | An https address we fetch server-side. For a file already on the web. | |
| name | No | Project name. | |
| base64 | No | The .dxf file bytes, base64-encoded. Max 6 MB decoded. Only usable if your own CODE fills this in — if the file is on disk, call create_upload and send `ticketId` instead. | |
| height | No | Extrusion depth in mm (default 5, minimum 0.1). | |
| ticketId | No | A create_upload ticket, minted for `dxf`, whose file has been PUT. | |
| unitFactor | No | Millimetres per file unit, overriding what the file declared. Set this only after reading the reported unit and finding it wrong — most DXFs declare one correctly. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/network profile is covered. The description adds genuinely useful behavior beyond that: closed outlines become editable extrude nodes, and the response reports declared units and unread entity types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core verb and resource, and each sentence carries information (parametric behavior, editable nodes, response contents). Slightly dense with three long clauses in the middle, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description compensates by describing what the response reports (declared units, unread entity types). Combined with full schema coverage and annotations covering safety, the definition is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across all six parameters, so the schema already documents url, base64, ticketId, height and unitFactor including the create_upload routing and the 6 MB limit. The description's unit-reporting sentence reinforces unitFactor's role but adds no new parameter syntax. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Import a DXF as a new project, extruded into solid geometry') and immediately differentiates itself from the sibling import_model by contrasting parametric vs mesh behavior. An agent can select it correctly without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The contrast with mesh import ('Unlike a mesh import this stays PARAMETRIC') gives clear context for when this tool is the right choice. However it stops short of explicitly naming import_model as the alternative or stating exclusions, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import an STL, OBJ or 3MF file as a new project — for geometry you did not author. STL and OBJ carry no unit, so pass unit if you know it; otherwise it is guessed and the guess is reported back so you can correct it. The response reports whether the mesh is watertight and what is wrong with it if not — a mesh that is not watertight cannot take part in a boolean, so check this before building on it.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | An https address we fetch server-side. For a file already on the web. | |
| name | No | Project name. | |
| unit | No | Unit the file is authored in. Guessed if omitted. | |
| base64 | No | The file bytes, base64-encoded. Max 6 MB decoded. Only usable if your own CODE fills this in — if the file is on disk, call create_upload and send `ticketId` instead. | |
| format | No | Required with `base64`; the ticket carries it otherwise. | |
| repair | No | Weld hairline cracks, close holes and fix face directions on the way in (default false). Off by default because it moves geometry; the response always reports whether it was needed, so import once, read `watertight`, and re-import with this set only if it says no. | |
| ticketId | No | A create_upload ticket whose file has been PUT. Carries its own format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give generic safety flags; the description adds substantive behavior beyond them: unit guessing with the guess reported back for correction, the response's watertight verdict, and the rule that a non-watertight mesh cannot participate in a boolean. This is exactly the context an agent needs before building on the import.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, purpose front-loaded and each clause carrying information (format list, unit handling, watertight consequence). Slightly packed, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, zero-required tool with no output schema, the description covers the two things the response reports (unit guess, watertight status) plus the repair decision loop. An agent has enough to invoke it correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: pass `unit` when known or accept a reported guess, and the staged repair workflow tied to the `repair` parameter's default-off rationale. It reinforces the schema rather than merely restating it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (import), resource (STL/OBJ/3MF mesh as a new project) and scope ('for geometry you did not author'), which cleanly separates it from siblings like import_2d, remix_project and the authoring tools. An agent can identify the tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for geometry you did not author' gives a clear when-to-use criterion, and the repair sentence prescribes a concrete workflow (import once, read watertight, re-import with repair only if needed). It stops short of naming sibling alternatives (e.g. create_upload, remix_project) explicitly, so no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report on a job handle you were given. A slow analysis on a SAVED project (evaluate, print_check, measure, check_interference) is finished in the background instead of failing, and answers with a jobId; call this with that id until status is "done", waiting retryAfterMs between polls. The result is exactly what the original tool would have returned. STEP jobs are polled with export_step, not here.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The handle from a deferred call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and idempotent, and the description adds substantial behavioral context beyond that: the job completes in the background instead of failing, polling must continue until status 'done', retryAfterMs controls poll spacing, and the result is exactly what the original tool would return. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The core action is front-loaded, the polling contract is stated compactly, and the key exclusion is at the end. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an async polling tool with one param and no output schema, this is complete: it defines the trigger, the polling loop, the stop condition, the wait interval, the result semantics, and the sibling tool to use instead for STEP jobs. An agent has everything needed to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds useful semantics by explaining that jobId is the handle received from a deferred call and that the same id should be used for polling. This goes beyond the schema's brief 'handle from a deferred call.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Report on a job handle you were given.' It precisely identifies which deferred operations it applies to (evaluate, print_check, measure, check_interference) and explicitly distinguishes itself from export_step, so an agent can tell it apart from siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: after a slow analysis on a SAVED project returns a jobId, poll with this tool until status is 'done', waiting retryAfterMs. It also gives an explicit exclusion: 'STEP jobs are polled with export_step, not here.' This is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Folders you own or belong to — where organize_project can file a project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the behavioral detail that the list is scoped to folders the user owns or belongs to, which is useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, and the purpose clause is directly relevant. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with full annotation coverage, the description is nearly complete. It could mention whether the list is paginated or sorted, but that's a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema has nothing to document. The description adds meaning by explaining what the folders represent and how they relate to organize_project, which is the only semantic content an agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('folders'), and adds a scoping detail ('you own or belong to'). It doesn't explicitly differentiate from sibling tools like list_projects or list_parts, but the resource is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case: finding a folder where organize_project can file a project. It doesn't explicitly state when to use this over list_projects or other list tools, but the connection to organize_project provides some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The parts OwlCAD ships — brackets, fasteners, spacers, board and motor reference bodies, mechanism pieces. Each is PARAMETRIC and datasheet-dimensioned, so a Raspberry Pi reference body has the real footprint and hole pattern. Insert one with an edit_project addPart op. Reach for this before hand-modelling something that sounds standard.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Keep only parts whose name or category contains this text. | |
| category | No | Keep only this category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds context beyond those annotations by noting that parts are parametric, datasheet-dimensioned, and that insertion happens through a separate edit_project addPart operation, clarifying that this tool only supplies the catalog.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each earning its place: contents, parametric nature, insertion path, and a usage heuristic. The most important scoping information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list with two optional params and full safety annotations, the description covers the catalog contents, part properties, and how to act on a result. It does not spell out the exact return shape, but the low complexity and schema coverage make the definition complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already described. The description adds value by enumerating example categories (brackets, fasteners, spacers, board/motor reference bodies, mechanism pieces), which helps the agent choose useful search or category values even though it does not describe the parameters directly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description make clear this tool browses OwlCAD's built-in parametric part library, naming concrete categories like brackets, fasteners, and reference bodies. It does not explicitly use a verb like 'list' in the description and does not name a sibling alternative, so it stops short of full 5-level differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use directive: reach for this before hand-modelling something that sounds standard. It also indicates the next step (insertion via edit_project addPart), but it does not name specific alternative tools or state when not to use this list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The authenticated account’s projects, most recently updated first — how to find an id for get_project.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Continue after this project id — pass the `nextCursor` from the previous call. Without it an account with more than 200 projects could never see past the first page. | |
| limit | No | Max rows (default 50, max 200). | |
| nameContains | No | Keep only projects whose name contains this text, case-insensitive. Applied to the page as it is read, so page through with `after` until `nextCursor` is absent rather than assuming one page holds every match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds ordering behavior ('most recently updated first') and authentication scope ('authenticated account's'), which go beyond the annotations. However, pagination and return format are not addressed in the description, leaving some transparency to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact clause that front-loads the action and purpose, with no filler words. It could be more grammatical, but the em dash effectively separates the what from the why. It earns its place while remaining short and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with rich schema (100% param coverage) and safety annotations, the description covers the essential context: the account scope, ordering, and intended use for get_project. It doesn't explicitly mention pagination or response fields, but those are documented in the schema or implied by the listing purpose. An agent can invoke it correctly with the given information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters (after, limit, nameContains), so the baseline is 3. The description does not add any parameter-level information, but the schema already carries that burden effectively. No extra semantics are introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('projects') and adds defining details: the authenticated account's projects, sorted by most recent update. The phrase 'how to find an id for get_project' gives a concrete downstream purpose, distinguishing it from get_project and other list_* siblings. Together with the title, it unambiguously specifies what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: finding an id for get_project, which tells the agent when to reach for this tool. It does not name alternatives or explain when not to use it, but the sibling context (get_project, list_folders, list_parts) makes the selection obvious. The absence of explicit exclusions prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact volume, surface area, centre of mass and connected-body count, plus an estimate of the filament a print would consume and what it would cost. Use it to answer "how heavy / how much material / how much filament / how much will this cost" — nothing else reports those, and they cannot be derived from a bounding box. Also checks a model is ONE body — two bodies where you expected one means operands that never touched.
| Name | Required | Description | Default |
|---|---|---|---|
| scad | No | OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset(). | |
| nodes | No | Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong. | |
| infill | No | Infill density 0–1 (default 0.15). | |
| shellMm | No | Solid skin thickness in mm (default 1.2). | |
| projectId | No | Id of one of your saved projects, as an alternative to `nodes`/`scad` (supply exactly one). | |
| materialId | No | Filament to cost it against (default "pla"). Ids come from the owlcad://materials resource. | |
| smoothness | No | Curve quality for shapes that left their segment count automatic. Defaults to "standard", which is the editor default — pass "high" to match a project authored at high smoothness, "draft" for a cheaper check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context: results are exact for geometry but an estimate for filament/cost, and a two-body count is a diagnostic signal about operands that never touched — a non-obvious interpretation an agent would otherwise miss.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, fully front-loaded with the output set first, then the use case, then the diagnostic behavior. Every clause carries information; no restatement of the name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must enumerate what comes back, and it does so precisely (six named quantities). It also supplies the estimation caveat on the filament/cost half, which is the main thing an agent could misread as exact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents scad/nodes/infill/shellMm/materialId/smoothness. The description adds no syntax, defaults or format guidance for any parameter, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a precise set of computed quantities (volume, surface area, centre of mass, connected-body count, filament estimate and cost) on a specific resource (a model), and asserts exclusivity — 'nothing else reports those'. An agent can tell this apart from evaluate/render/print_check without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete triggering questions ('how heavy / how much material / how much filament / how much will this cost') and a negative boundary ('cannot be derived from a bounding box'). It stops short of naming the sibling to use instead for interference or printability questions, so the routing is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The URL that opens a saved project in the OwlCAD editor.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The saved project to link to. The link works only for its owner. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, and non-destructive behavior, so the description only needs to add context. It does indicate that the result is a URL, which is useful, but it does not go beyond that with ownership, auth, or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or filler content. Every word contributes to identifying what the tool returns and for what purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter, read-only link tool, the description combined with the schema and annotations is nearly complete: it identifies the input, the output as a URL, and the read-only nature. It only lacks explicit usage boundaries or caveats, so it does not reach a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the projectId parameter is already described clearly, including the owner-only restriction. The tool description does not need to add parameter semantics because the schema fully covers the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides the URL that opens a saved project in the OwlCAD editor, using a specific verb and resource. It is distinguishable from editing, exporting, or rendering tools, though it does not explicitly contrast itself with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided, and no alternative tools are mentioned. An agent must infer from the title and description that this is for obtaining an editor link, without any explicit usage conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move one of your projects into a folder, or out of one. Folders are how a shared workspace is organized — a project filed into one inherits that folder’s members. Call with no folderId to take it out again. Use list_folders to see which folders you can file into.
| Name | Required | Description | Default |
|---|---|---|---|
| folderId | No | Folder to file it into. Omit (or null) to remove it from its folder. | |
| projectId | Yes | The project to file — one of yours. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is idempotent and non-destructive. The description adds useful behavioral context by explaining that a filed project inherits the folder's members and that omitting folderId removes the project from its folder, which goes beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. It front-loads the core action, then provides the key behavioral consequence (folder membership inheritance) and the concrete removal instruction, all in a compact, well-structured format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with complete schema coverage and relevant annotations, the description covers the main operation, the removal case, the organizational context, and how to discover valid folders. No critical invocation detail appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds little beyond the schema, though it reinforces the folderId-omission behavior already stated in the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action—moving a project into or out of a folder—and distinguishes it from sibling tools like list_folders. The title and first sentence align and leave no ambiguity about the tool's resource and operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage instructions for both filing (with folderId) and unfiling (without folderId). It also points to list_folders for discovering available folders, though it doesn't explicitly state when not to use the tool or contrast it with alternatives like delete_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyse a model for 3D-printing problems: overhang area beyond the safe angle, and the thinnest wall. Use this before calling a part done — it is the check you cannot do by reasoning about the tree, and evaluate does not answer it. If the request mentions supports, overhangs, thin walls, or whether a part fits the bed or will print at all, this tool is the only thing that answers it.
| Name | Required | Description | Default |
|---|---|---|---|
| scad | No | OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset(). | |
| nodes | No | Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong. | |
| minWallMm | No | Thinnest acceptable wall in mm (default 0.8). | |
| printerId | No | Check whether the model fits a specific printer’s build volume. Ids come from the owlcad://printers resource. | |
| projectId | No | Id of one of your saved projects, as an alternative to `nodes`/`scad` (supply exactly one). | |
| smoothness | No | Curve quality for shapes that left their segment count automatic. Defaults to "standard", which is the editor default — pass "high" to match a project authored at high smoothness, "draft" for a cheaper check. | |
| overhangDeg | No | Overhang angle treated as unsupported (default 45). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds that this is a check that cannot be done by reasoning about the tree, but says nothing about return shape, cost, or the printerId fit-check behavior beyond what the schema states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb and the two checks, then usage. Three sentences, each earning its place, though the final sentence partially restates the second.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description could hint at what the analysis returns (measurements vs pass/fail), which is a minor gap. Otherwise, with annotations covering safety and the schema covering all params, an agent has enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters, including overhangDeg, minWallMm and printerId. The description's mention of overhangs, thin walls and bed fit maps to those params but adds no syntax or format detail beyond the schema; baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — analyses a model for two named printability problems (overhang area beyond safe angle, thinnest wall). It also explicitly distinguishes itself from the sibling `evaluate`, which an agent can use to route correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('before calling a part done'), names the alternative it is not (`evaluate` does not answer it), and enumerates triggering request terms (supports, overhangs, thin walls, bed fit). This is a textbook routing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads an owlcad:// resource as a tool result, for clients that do not let you read MCP resources — any owlcad:// URI these tools tell you to read works here. owlcad://schema/primitives without keys is an index; pass keys for the full parameter ranges of the entries you will use.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes | The owlcad:// URI to read. | |
| keys | No | owlcad://schema/primitives only: names to return in full, e.g. ["box","enclosure"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is read-only, idempotent, non-destructive, and not open-world. The description adds useful behavioral context beyond those: the fallback role for clients without MCP resource support, and the key-dependent behavior of returning an index vs. full parameter ranges. This supplements rather than repeats structured data, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the core purpose and the specific client context that warrants using the tool. The second sentence delivers the most important parameter behavior. Every word contributes to correct agent selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with a complete input schema and no output schema, the description covers purpose, usage context, and the key semantic nuance. It does not describe the exact response content, but for a resource-reader that is largely determined by the URI and known to the agent. With annotations covering safety and idempotence, the description is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing parameter names and enum values. The description adds semantic value by explaining the behavioral difference when `keys` is omitted vs. provided for owlcad://schema/primitives, and notes that 'any owlcad:// URI these tools tell you to read works here' — meaning the URI parameter is not just a static enum but tied to tool-referenced resources. This is meaningful added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair: 'Reads an owlcad:// resource as a tool result.' It also clarifies the scope by noting any owlcad:// URI referenced by other tools works here, which distinguishes it from schema-only reading implied by the title. The enum in the schema reinforces the resource types without needing repetition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames when to use this tool: for clients that do not let you read MCP resources directly. It also provides conditional guidance for passing `keys` on owlcad://schema/primitives to receive full parameter ranges rather than an index. It does not name alternative tools because no sibling tool serves the same read-resource function, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fork a PUBLIC project into a new one you own, keeping the lineage link back to the original. This is how you start from someone else’s published model instead of from nothing. Only public projects can be remixed; to copy one of your own, read it and save the tree as a new project.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The public project to fork. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only provide generic false hints, so the description carries the burden. It transparently discloses that the tool creates a new project you own, preserves a lineage link, and is restricted to public projects. This adds meaningful behavioral context beyond the structured fields, though it does not cover failure/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no fluff. The primary action is front-loaded, followed by usage context and the constraint/alternative. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description explains the core function, when to use it, the public-project constraint, and how to handle your own projects. It could mention what the tool returns (e.g., new project ID), but this is not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes projectId as 'The public project to fork' with 100% coverage. The description reinforces the 'public' constraint but adds little new information about the parameter itself. Per the rubric, baseline 3 is appropriate when schema covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Fork a PUBLIC project into a new one you own') and distinguishes this from copying your own project by pointing to an alternative. This makes the tool's purpose unambiguous and differentiates it from siblings like get_project and save_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool ('start from someone else's published model') and when not to ('to copy one of your own, read it and save the tree as a new project'). It also states the precondition that only public projects can be remixed. This is complete usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render the model to PNG images you can actually look at, from one or more named views. Use this to CHECK your work — a tree that evaluates cleanly can still be the wrong shape, and this is the only way to notice. Flat-shaded diagnostic render, not a marketing shot.
| Name | Required | Description | Default |
|---|---|---|---|
| scad | No | OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset(). | |
| size | No | Square image size in px (default 512, max 1024). | |
| nodes | No | Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong. | |
| views | No | Views to render (default ["iso"]). Up to 4. | |
| projectId | No | Id of one of your saved projects, as an alternative to `nodes`/`scad` (supply exactly one). | |
| azimuthDeg | No | Look from a specific angle instead of a named view: degrees around the model, 0 = the front view, increasing towards the right. Use with `elevationDeg`; ignores `views`. | |
| smoothness | No | Curve quality for shapes that left their segment count automatic. Defaults to "standard", which is the editor default — pass "high" to match a project authored at high smoothness, "draft" for a cheaper check. | |
| elevationDeg | No | Height of the camera in degrees above the horizontal (−90 to 90). Use with `azimuthDeg`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's added value is the output character: PNG images, flat-shaded diagnostic style rather than a marketing shot. That tells the agent what it will actually get back, which annotations cannot convey, though it stops short of describing how images are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero padding, with the core action front-loaded and the diagnostic framing and output style following immediately. Every sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully characterizes the return (viewable PNG renders, flat-shaded). Given the richly documented 8-param schema and read-only annotations, an agent has enough to call it correctly, though a hint about how many/how the images are delivered would close the last gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including scad/nodes/projectId mutual exclusion, view enums, azimuth/elevation, and smoothness is already fully documented. The description only restates the 'one or more named views' idea, adding nothing the schema lacks — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (render), the resource (the model), the output form (PNG images), and the controlling input (named views). It also distinguishes itself from sibling evaluate by noting that a tree can evaluate cleanly yet still be the wrong shape — an agent can route between the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use context: to CHECK your work after building, and implicitly after evaluate passes. It does not name evaluate or open_in_editor explicitly as alternatives, but the framing ('this is the only way to notice') supplies the selection rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find every imported mesh in one of your projects that is not watertight, and weld cracks, close holes and fix face directions. A non-watertight mesh cannot take part in a boolean — the evaluator degrades it to nothing — so a model built on one comes back missing a part with no error anywhere. Run this when a project contains an import and the geometry is not behaving. Pass dryRun to see what is broken without changing it.
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | Report what is broken and change nothing (default false). | |
| nodeId | No | Repair only this mesh node. Omit to repair every broken one. | |
| version | No | The `version` get_project reported. Required only once a repair will actually write — a dry run, a project with no imported meshes, and one whose meshes are already sound all answer without it. | |
| projectId | Yes | The project whose imported meshes to check and repair. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds valuable behavioral context beyond that: it explains the silent-failure mode of non-watertight meshes, the specific repair actions, and the dryRun parameter that lets the caller avoid changes. It does not exhaustively describe all side effects (e.g., whether original mesh data is overwritten), but it meaningfully supplements the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and every sentence earns its place: the first states what it does, the second explains the practical consequence of broken meshes (why it matters), and the third gives a direct usage directive plus a pointer to dryRun. It is front-loaded with the primary action and has zero filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, four-parameter tool with no output schema, the description covers the core trigger, action, and dryRun behavior. However, it does not describe what the tool returns after a non-dryRun repair (e.g., a report, a list of repaired node IDs, or a job reference) nor mention any asynchronous behavior or version requirement, beyond what the schema already states. An agent cannot fully predict the outcome of a successful repair, which is a genuine gap given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description goes beyond the schema by explaining the purpose of dryRun ('Pass `dryRun` to see what is broken without changing it') and implicitly clarifying that projectId identifies the project whose meshes are checked. It also reinforces the meaning of nodeId through the phrase 'every imported mesh' vs. a single node, though the schema already handles that. This extra semantic layer justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Find every imported mesh in one of your projects that is not watertight, and weld cracks, close holes and fix face directions.' This clearly states the action and scope, and the repair behavior (welding, closing holes, fixing face directions) makes it unmistakably distinct from sibling tools like check_interference or edit_nodes. The title and description align, and an agent can tell exactly what the tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Run this when a project contains an import and the geometry is not behaving,' providing clear conditions for use. It also explains the underlying motivation (non-watertight meshes silently break booleans) and mentions the dryRun option to preview changes. However, it does not name alternative tools or explicitly state when not to use it, such as for projects without imports, so it falls just short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a model as a project on the authenticated account, returning its id. Pair with open_in_editor to hand a person an editable link — that is usually a better deliverable than a bare mesh file.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Project name. | |
| scad | No | OpenSCAD source, as an alternative to `nodes`. Saved as the editor’s .scad import saves it: top-level options become project variables, but one that picks an if/for is fixed, and part names are generated. For a fully live script send it in `nodes` as a scad generator. | |
| nodes | No | Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the agent knows this writes without destroying. The description adds that the result is tied to the authenticated account and returns an id, but it does not clarify whether repeated calls create duplicates (relevant given idempotentHint=false) or what side effects saving has.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core action front-loaded, and no wasted filler. The second sentence is somewhat advisory rather than definitional, but it still earns its place as a routing hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully discloses that an id is returned. However, for a mutation tool handling a rich parametric node tree, it says nothing about what a 'project' persists, overwrite behavior, or failure modes, leaving meaningful gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents name, scad and nodes, including the elaborate node-tree semantics and resource references. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Save a model as a project'), notes it operates on the authenticated account, and says it returns an id, which signals a creation operation. It does not, however, differentiate itself from the closely named siblings update_project or edit_project, leaving the create-vs-update distinction to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a follow-up recommendation ('Pair with open_in_editor ... usually a better deliverable than a bare mesh file'), which is genuine usage guidance. But it never says when to choose this over update_project/edit_project, or what prerequisites exist, so the primary selection question is left implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cut one body in a project into two halves at a plane, with a joint so they go back together after printing. This is the answer to "my model is too big for my printer". Both halves stay fully parametric — each is the original body intersected with a half-space, not a flattened mesh — so they still export as solids and still open for editing. Pick the joint by what the print needs: dowel puts a socket in BOTH halves and prints the pin separately, so neither half has anything standing off its cut face and a wrong fit costs a two-gram reprint instead of a whole half; pin and tenon grow the key out of one half; bolt is the only one that comes apart again. Omit position to cut through the middle of the body on that axis.
| Name | Required | Description | Default |
|---|---|---|---|
| fit | No | How much slack the key gets in its socket. Defaults to normal (0.2 mm). Use `custom` with `gap` to set it yourself. | |
| gap | No | The clearance in mm when `fit` is custom. | |
| axis | No | Which way the plane faces. Cut a tall part across z, a long one across x. Defaults to z. | |
| size | No | Key size in mm — pin/dowel diameter, tenon width, bolt size. Defaults to 5. | |
| count | No | How many keys across the cut face (1-6). Defaults to 2. | |
| depth | No | How far a key reaches into the far half, mm. For a dowel, into EACH half. Defaults to 6. | |
| joint | No | Defaults to pin. | |
| shape | No | Key cross-section (pin and dowel only). Round lets the halves spin about a single key; any other shape stops that. Defaults to circle. | |
| style | No | Straight or tapered (pin and dowel only). Tapered is easier to start and shrinks the flat bridge over a blind socket. Defaults to prism. | |
| nodeId | Yes | The top-level body to cut, from `get_project`. A nested node, a generator or a component instance cannot be cut — the cut is authored in world coordinates. | |
| version | No | The `version` get_project reported, so a concurrent change is detected rather than overwritten. | |
| position | No | Where the plane sits along `axis`, in world mm. Must pass THROUGH the body — the reply names the legal range if it does not. Omit to cut at the middle, which is almost always what you want. | |
| projectId | Yes | The project containing the body to cut. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint=true, so the description carries a heavy burden. It goes far beyond that: it reveals that both halves remain parametric solids, explains the practical consequences of each joint type (e.g., dowel prints pin separately, bolt comes apart), and states what omitting position does. This matches and richly supplements the destructive annotation without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and remains information-dense throughout; every clause explains a behavioral nuance. It is slightly long given the many joint details, but those details are load-bearing for correct selection, so the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with no output schema, the description supplies the most important decision factors: joint behavior, parametric preservation, and position default. It does not describe return values or error messages, but the schema covers parameters and annotations cover destructiveness, so the main gaps are minor and do not block correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though the schema already has 100% coverage with detailed descriptions, the prose adds crucial meaning: it defines the trade-offs among pin, tenon, dowel, and bolt; notes that round keys allow spinning; and explains the default middle-cut behavior of position. This is exactly the kind of cross-parameter guidance an agent needs to select joint and position correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Cut one body in a project into two halves at a plane, with a joint'. It directly answers the canonical use case, 'my model is too big for my printer', and clearly distinguishes this from sibling tools like repair_project or export_step by describing its unique cut-and-joint behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly identifies when to use the tool: when a model does not fit the printer bed. It does not explicitly name sibling alternatives or exclusion criteria, but the use case is specific enough that an agent can route correctly; it also gives guidance on choosing joint types and omitting position.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the geometry of one of your existing projects, keeping its id, link and history. Pass the version you got from get_project — if the project has changed since, the update is refused rather than silently overwriting that change. Use this instead of save_project when iterating, so a person keeps one link.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Rename the project at the same time (optional). | |
| scad | No | OpenSCAD source, as an alternative to `nodes`. Saved as the editor’s .scad import saves it: top-level options become project variables, but one that picks an if/for is fixed, and part names are generated. For a fully live script send it in `nodes` as a scad generator. | |
| nodes | No | Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong. | |
| version | Yes | The `version` get_project reported. A mismatch means someone else changed it — re-read and retry. | |
| projectId | Yes | The project to overwrite. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=false, so the safety profile is known. The description adds what annotations cannot: optimistic concurrency — a stale `version` causes a refusal rather than a silent overwrite — and the fact that identity/link/history survive the geometry replacement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action and its preserved invariants, then the concurrency contract, then the sibling routing. Every sentence earns its place with no restatement of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but for a mutation tool this is fine — the description covers what changes, what is preserved, and the failure mode. The only unstated item is what a successful response returns, which is minor given the operation's shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all five parameters, including the version-mismatch retry note on `version`. The description's restatement of `version` provenance adds only marginal value beyond the structured fields, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Replace the geometry of one of your existing projects') plus the invariant it preserves (id, link, history). It explicitly distinguishes itself from the sibling save_project, so an agent can route correctly without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit alternative and the condition that selects it: 'Use this instead of save_project when iterating, so a person keeps one link.' It also names the prerequisite flow via get_project to obtain `version`, which is the one piece of sequencing an agent must get right.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_interference1 field changedInput schema / properties / nodes / descriptionPrevious value: -"Parametric node tree. mm, Z-up, rotations in DEGREES. Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."New value: +"Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."edit_nodes1 field changedInput schema / properties / nodes / descriptionPrevious value: -"Parametric node tree. mm, Z-up, rotations in DEGREES. Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."New value: +"Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."evaluate1 field changedInput schema / properties / nodes / descriptionPrevious value: -"Parametric node tree. mm, Z-up, rotations in DEGREES. Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."New value: +"Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."export1 field changedInput schema / properties / nodes / descriptionPrevious value: -"Parametric node tree. mm, Z-up, rotations in DEGREES. Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."New value: +"Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."export_2d6 fields changedInput schema / properties / arcsAdded value: +{
+ "description": "Default true: facets become true circles and arcs.",
+ "type": "boolean"
+}Input schema / properties / cutAdded value: +{
+ "description": "SVG: hairline laser cut lines, no fill.",
+ "type": "boolean"
+}Input schema / properties / format / descriptionPrevious value: -"File format: DXF for CAD/CAM and laser software, SVG for vinyl cutters and the web."New value: +"DXF for CAD/CAM and lasers, SVG for cutters and the web."Input schema / properties / nodes / descriptionPrevious value: -"Parametric node tree. mm, Z-up, rotations in DEGREES. Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."New value: +"Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."Input schema / properties / viewAdded value: +{
+ "description": "Default \"top\"; \"front\" from −y, \"right\" from +x.",
+ "enum": [
+ "top",
+ "front",
+ "right"
+ ],
+ "type": "string"
+}Input schema / properties / z / descriptionPrevious value: -"Slice height in mm (mode=section). The response reports the model’s z range when this misses it."New value: +"Section position, mm, on the view axis (z, y or x)."export_step1 field changedInput schema / properties / fit / descriptionPrevious 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."measure1 field changedInput schema / properties / nodes / descriptionPrevious value: -"Parametric node tree. mm, Z-up, rotations in DEGREES. Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."New value: +"Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."print_check1 field changedInput schema / properties / nodes / descriptionPrevious value: -"Parametric node tree. mm, Z-up, rotations in DEGREES. Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."New value: +"Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."render1 field changedInput schema / properties / nodes / descriptionPrevious value: -"Parametric node tree. mm, Z-up, rotations in DEGREES. Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."New value: +"Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."save_project1 field changedInput schema / properties / nodes / descriptionPrevious value: -"Parametric node tree. mm, Z-up, rotations in DEGREES. Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."New value: +"Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."update_project1 field changedInput schema / properties / nodes / descriptionPrevious value: -"Parametric node tree. mm, Z-up, rotations in DEGREES. Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."New value: +"Parametric node tree. mm, Z-up, rotations in DEGREES (a rotation.* binding: radians). Read owlcad://schema/primitives for every primitive, modifier and generator and its parameter ranges (unknown params are dropped silently), and owlcad://schema/conventions for the placement arithmetic, which is where most models go wrong."export_step1 field changedInput schema / properties / keepFacetsAdded 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"
+}save_project1 field changedInput schema / properties / scad / descriptionPrevious value: -"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset()."New value: +"OpenSCAD source, as an alternative to `nodes`. Saved as the editor’s .scad import saves it: top-level options become project variables, but one that picks an if/for is fixed, and part names are generated. For a fully live script send it in `nodes` as a scad generator."update_project1 field changedInput schema / properties / scad / descriptionPrevious value: -"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset()."New value: +"OpenSCAD source, as an alternative to `nodes`. Saved as the editor’s .scad import saves it: top-level options become project variables, but one that picks an if/for is fixed, and part names are generated. For a fully live script send it in `nodes` as a scad generator."check_interference1 field changedInput schema / properties / nodes / items / properties / generatorKey / descriptionPrevious value: -"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap."New value: +"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap · pillowBlock."edit_nodes1 field changedInput schema / properties / nodes / items / properties / generatorKey / descriptionPrevious value: -"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap."New value: +"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap · pillowBlock."edit_project7 fields changedInput schema / properties / ops / items / properties / customizerAdded value: +{
+ "description": "Makes the variable a control on the public Customize page (addVariable · setVariable): {public, label, control, min, max, step, unit, group, choices}. control must suit the kind — number: slider|number|toggle|dropdown (dropdown needs choices: [{value, label?}], numeric values); text: text; color: color. A variable drives nothing until a bind op points a node at it.",
+ "type": "object"
+}Input schema / properties / ops / items / properties / expr / descriptionPrevious value: -"The variable’s expression (addVariable · setVariable) — may reference other variables. addVariable creates one; setVariable changes an existing one."New value: +"The variable’s expression (addVariable · setVariable) — may reference other variables. addVariable creates one; setVariable changes an existing one. For bind: the formula (or text/color variable name) that drives `key`; \"\" unbinds."Input schema / properties / ops / items / properties / id / descriptionPrevious value: -"Target node id (updateParams · updateTransform · updateProps · removeNode · reorderNode · reparentNode · wrapModifier · setScriptSource)."New value: +"Target node id (updateParams · updateTransform · updateProps · removeNode · reorderNode · reparentNode · wrapModifier · setScriptSource · bind)."Input schema / properties / ops / items / properties / keyAdded value: +{
+ "description": "What to drive (bind): a param key, position.x|y|z, rotation.x|y|z (radians), scale.x|y|z, \"color\", or \"present\".",
+ "type": "string"
+}Input schema / properties / ops / items / properties / kindAdded value: +{
+ "description": "Variable type (addVariable); number is the default.",
+ "enum": [
+ "number",
+ "text",
+ "color"
+ ],
+ "type": "string"
+}Input schema / properties / ops / items / properties / node / descriptionPrevious value: -"The node to insert (addNode) — same shape as a `nodes` entry: {kind, name, type|op|generatorKey, params, transform}. For kind=generator, generatorKey is one of: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap. See owlcad://schema/primitives for parameter ranges and owlcad://schema/conventions for placement."New value: +"The node to insert (addNode) — same shape as a `nodes` entry: {kind, name, type|op|generatorKey, params, transform}. For kind=generator, generatorKey is one of: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap · pillowBlock. See owlcad://schema/primitives for parameter ranges and owlcad://schema/conventions for placement."Input schema / properties / ops / items / properties / op / enumPrevious value: -[
- "updateParams",
- "updateTransform",
- "updateProps",
- "addNode",
- "removeNode",
- "reorderNode",
- "reparentNode",
- "group",
- "wrapModifier",
- "addVariable",
- "setVariable",
- "setActiveConfig",
- "ungroup",
- "unwrapModifier",
- "bakeGenerator",
- "makeComponent",
- "addInstance",
- "removeComponent",
- "addPart",
- "addScript",
- "setScriptSource",
- "duplicate",
- "setScadFile",
- "removeScadFile"
-]New value: +[
+ "updateParams",
+ "updateTransform",
+ "updateProps",
+ "addNode",
+ "removeNode",
+ "reorderNode",
+ "reparentNode",
+ "group",
+ "wrapModifier",
+ "addVariable",
+ "setVariable",
+ "bind",
+ "setActiveConfig",
+ "ungroup",
+ "unwrapModifier",
+ "bakeGenerator",
+ "makeComponent",
+ "addInstance",
+ "removeComponent",
+ "addPart",
+ "addScript",
+ "setScriptSource",
+ "duplicate",
+ "setScadFile",
+ "removeScadFile"
+]evaluate1 field changedInput schema / properties / nodes / items / properties / generatorKey / descriptionPrevious value: -"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap."New value: +"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap · pillowBlock."export1 field changedInput schema / properties / nodes / items / properties / generatorKey / descriptionPrevious value: -"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap."New value: +"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap · pillowBlock."export_2d1 field changedInput schema / properties / nodes / items / properties / generatorKey / descriptionPrevious value: -"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap."New value: +"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap · pillowBlock."measure1 field changedInput schema / properties / nodes / items / properties / generatorKey / descriptionPrevious value: -"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap."New value: +"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap · pillowBlock."print_check1 field changedInput schema / properties / nodes / items / properties / generatorKey / descriptionPrevious value: -"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap."New value: +"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap · pillowBlock."read_resourcerender1 field changedInput schema / properties / nodes / items / properties / generatorKey / descriptionPrevious value: -"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap."New value: +"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap · pillowBlock."save_project1 field changedInput schema / properties / nodes / items / properties / generatorKey / descriptionPrevious value: -"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap."New value: +"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap · pillowBlock."update_project1 field changedInput schema / properties / nodes / items / properties / generatorKey / descriptionPrevious value: -"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap."New value: +"Generator to expand (kind=generator). PREFER one over hand-building the same thing — they carry standards dimensions and solve fits a tree of primitives gets subtly wrong: gearTrain · planetary · rackPinion · wormDrive · herringbone · herringboneTrain · pulley · bearing · belt · spring · adapter · boardMount · enclosure · gridfinity · threadedJar · pinHinge · snapFit · ballSocket · fastener · textPlate · fitCoupon · calibrationBlock · clamp · impeller · axialFan · fanFrame · plugCap · pillowBlock."check_interference1 field changedInput schema / properties / scad / descriptionPrevious value: -"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses. minkowski() and resize() are not supported here — use hull() or offset()."New value: +"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset()."edit_project3 fields changedInput schema / properties / ops / items / properties / op / enumPrevious value: -[
- "updateParams",
- "updateTransform",
- "updateProps",
- "addNode",
- "removeNode",
- "reorderNode",
- "reparentNode",
- "group",
- "wrapModifier",
- "addVariable",
- "setVariable",
- "setActiveConfig",
- "ungroup",
- "unwrapModifier",
- "bakeGenerator",
- "makeComponent",
- "addInstance",
- "removeComponent",
- "addPart",
- "addScript",
- "setScriptSource",
- "duplicate"
-]New value: +[
+ "updateParams",
+ "updateTransform",
+ "updateProps",
+ "addNode",
+ "removeNode",
+ "reorderNode",
+ "reparentNode",
+ "group",
+ "wrapModifier",
+ "addVariable",
+ "setVariable",
+ "setActiveConfig",
+ "ungroup",
+ "unwrapModifier",
+ "bakeGenerator",
+ "makeComponent",
+ "addInstance",
+ "removeComponent",
+ "addPart",
+ "addScript",
+ "setScriptSource",
+ "duplicate",
+ "setScadFile",
+ "removeScadFile"
+]Input schema / properties / ops / items / properties / pathAdded value: +{
+ "description": "Project file path scripts include, e.g. lib/dims.scad (setScadFile · removeScadFile).",
+ "type": "string"
+}Input schema / properties / ops / items / properties / source / descriptionPrevious value: -"OpenSCAD script text (addScript · setScriptSource); its Customizer comments become the node’s params."New value: +"OpenSCAD text (addScript · setScriptSource · setScadFile); a script’s Customizer comments become its params."evaluate1 field changedInput schema / properties / scad / descriptionPrevious value: -"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses. minkowski() and resize() are not supported here — use hull() or offset()."New value: +"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset()."export1 field changedInput schema / properties / scad / descriptionPrevious value: -"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses. minkowski() and resize() are not supported here — use hull() or offset()."New value: +"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset()."export_2d1 field changedInput schema / properties / scad / descriptionPrevious value: -"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses. minkowski() and resize() are not supported here — use hull() or offset()."New value: +"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset()."measure1 field changedInput schema / properties / scad / descriptionPrevious value: -"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses. minkowski() and resize() are not supported here — use hull() or offset()."New value: +"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset()."print_check1 field changedInput schema / properties / scad / descriptionPrevious value: -"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses. minkowski() and resize() are not supported here — use hull() or offset()."New value: +"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset()."render1 field changedInput schema / properties / scad / descriptionPrevious value: -"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses. minkowski() and resize() are not supported here — use hull() or offset()."New value: +"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset()."save_project1 field changedInput schema / properties / scad / descriptionPrevious value: -"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses. minkowski() and resize() are not supported here — use hull() or offset()."New value: +"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset()."update_project1 field changedInput schema / properties / scad / descriptionPrevious value: -"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses. minkowski() and resize() are not supported here — use hull() or offset()."New value: +"OpenSCAD source, as an alternative to `nodes` (supply exactly one). Interpreted by the same engine the editor’s .scad import uses; BOSL2/MCAD includes resolve. minkowski() and resize() are not supported here — use hull() or offset()."delete_project1 field changedInput schema / properties / projectId / descriptionAdded value: +"The project to delete permanently — one you created."edit_project6 fields changedInput schema / properties / ops / items / properties / id / descriptionPrevious value: -"Target node id (updateParams · updateTransform · updateProps · removeNode · reorderNode · reparentNode · wrapModifier)."New value: +"Target node id (updateParams · updateTransform · updateProps · removeNode · reorderNode · reparentNode · wrapModifier · setScriptSource)."Input schema / properties / ops / items / properties / ids / descriptionPrevious value: -"Node ids — two or more to combine (group), one or more to turn into a component (makeComponent). For group with booleanOp=\"difference\" the ORDER is significant: the first id is the body that is kept and every later id is subtracted from it. List the blank first, then the cutters — reversed, you subtract the body from the cutter and usually get an empty result."New value: +"Node ids — two or more to combine (group), one or more to turn into a component (makeComponent) or copy (duplicate). For group with booleanOp=\"difference\" the ORDER is significant: the first id is the body that is kept and every later id is subtracted from it. List the blank first, then the cutters — reversed, you subtract the body from the cutter and usually get an empty result."Input schema / properties / ops / items / properties / name / descriptionPrevious value: -"Node name (updateProps) · variable name (addVariable · setVariable) · component name (makeComponent · addInstance)."New value: +"Node name (updateProps · addScript) · variable name (addVariable · setVariable) · component name (makeComponent · addInstance)."Input schema / properties / ops / items / properties / op / enumPrevious value: -[
- "updateParams",
- "updateTransform",
- "updateProps",
- "addNode",
- "removeNode",
- "reorderNode",
- "reparentNode",
- "group",
- "wrapModifier",
- "addVariable",
- "setVariable",
- "setActiveConfig",
- "ungroup",
- "unwrapModifier",
- "bakeGenerator",
- "makeComponent",
- "addInstance",
- "removeComponent",
- "addPart"
-]New value: +[
+ "updateParams",
+ "updateTransform",
+ "updateProps",
+ "addNode",
+ "removeNode",
+ "reorderNode",
+ "reparentNode",
+ "group",
+ "wrapModifier",
+ "addVariable",
+ "setVariable",
+ "setActiveConfig",
+ "ungroup",
+ "unwrapModifier",
+ "bakeGenerator",
+ "makeComponent",
+ "addInstance",
+ "removeComponent",
+ "addPart",
+ "addScript",
+ "setScriptSource",
+ "duplicate"
+]Input schema / properties / ops / items / properties / ref / descriptionPrevious value: -"Label for the node this op creates, so a LATER op in the same call can name it as \"@label\" wherever a node id goes (addNode · group) — the only way to subtract a cutter you just added from a body that is not already a difference, and on `group` the only way to build in TWO STAGES: group A and B with a ref, then name that ref to subtract C from the result. Without it the operands of a group stop being top-level and cannot be named again. The label lives for this call only and never reaches the document, which keeps caller-chosen ids out of it. Must be unique within the call and declared before it is used; otherwise the op naming it is refused."New value: +"Label for the node this op creates, so a LATER op in the same call can name it as \"@label\" wherever a node id goes (addNode · group · addScript · duplicate) — the only way to subtract a cutter you just added from a body that is not already a difference, and on `group` the only way to build in TWO STAGES: group A and B with a ref, then name that ref to subtract C from the result. Without it the operands of a group stop being top-level and cannot be named again. The label lives for this call only and never reaches the document, which keeps caller-chosen ids out of it. Must be unique within the call and declared before it is used; otherwise the op naming it is refused."Input schema / properties / ops / items / properties / sourceAdded value: +{
+ "description": "OpenSCAD script text (addScript · setScriptSource); its Customizer comments become the node’s params.",
+ "type": "string"
+}export1 field changedInput schema / properties / format / descriptionAdded value: +"File format. 3MF keeps each top-level part as its own named, coloured object; STL is one fused mesh."export_2d1 field changedInput schema / properties / format / descriptionAdded value: +"File format: DXF for CAD/CAM and laser software, SVG for vinyl cutters and the web."get_project1 field changedInput schema / properties / projectId / descriptionAdded value: +"The project to load — one of yours; see `list_projects`."open_in_editor1 field changedInput schema / properties / projectId / descriptionAdded value: +"The saved project to link to. The link works only for its owner."organize_project1 field changedInput schema / properties / projectId / descriptionAdded value: +"The project to file — one of yours."repair_project1 field changedInput schema / properties / projectId / descriptionAdded value: +"The project whose imported meshes to check and repair."share_project1 field changedInput schema / properties / projectId / descriptionAdded value: +"The project to share or unshare — one of yours."split_for_printing1 field changedInput schema / properties / projectId / descriptionAdded value: +"The project containing the body to cut."ask_helpcheck_interferencecreate_uploaddelete_projectedit_nodesedit_projectevaluateexportexport_2dexport_stepget_projectimport_2dimport_modeljob_statuslist_folderslist_partslist_projectsmeasureopen_in_editororganize_projectprint_checkremix_projectrenderrepair_projectsave_projectshare_projectsplit_for_printingupdate_project
Add one secure layer between your agents and this server.