kernelcad

Add Variable Sweep

add_variable_sweep

Use this when you need an organic swept solid whose cross-section changes along its length — a tapering body, horn, bottle, fairing, or duct — authored as a variable-section sweep along a spine. Insert a variableSweep(spine, sections, opts?) declaration into the user's .kcad.ts immediately before the last top-level return. The result is a Shape — chain .translate(...), .union(...), etc. via add_feature. spine_binding references an existing variable (Curve3D / Sketch / Vec3[]) in the source; each sections[i].profile_binding references an existing Sketch. Sections must be strictly increasing in t and span [0, 1]; first t=0, last t=1. Orientation is not exposed by this MCP tool until runtime orientation support is wired. Validates every binding exists in the source via regex before inserting (fast structured error vs capture-time stack). Returns the modified code + diagnostics. Side-effect-free.

Input Schema

TableJSON Schema

Name	Required	Description
`code`	Yes	The .kcad.ts source code.
`closed`	No	Optional closed-sweep flag.
`sections`	Yes	Varying cross-sections along the spine; at least 2 entries, strictly increasing in `t`, first t=0, last t=1.
`continuity`	No	Inter-section continuity; default 'C1'.
`binding_name`	No	JS const name for the new Shape binding (default: _sweep_<N>).
`spine_binding`	Yes	Existing variable name for a Curve3D / Sketch / Vec3[] declared earlier in the source.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether the edit applied and re-evaluated cleanly.
`error`	No	Failure message (present when ok is false).
`new_code`	No	Modified .kcad.ts source (present on success). Caller persists it.
`diagnostics`	No	Diagnostics from re-evaluating the modified source.
`binding_name`	No	JS const name bound to the new construct (when one was created).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedJun 15, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "binding_name": {
+      "description": "JS const name bound to the new construct (when one was created).",
+      "type": "string"
+    },
+    "diagnostics": {
+      "description": "Diagnostics from re-evaluating the modified source.",
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "error": {
+      "description": "Failure message (present when ok is false).",
+      "type": "string"
+    },
+    "new_code": {
+      "description": "Modified .kcad.ts source (present on success). Caller persists it.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "Whether the edit applied and re-evaluated cleanly.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}

Changed1 schema field changedJun 7, 2026

changedInput schema / properties / sections / description

Previous value: -"Varying cross-sections along the spine; at least 2 entries, strictly increasing in `t`."New value: +"Varying cross-sections along the spine; at least 2 entries, strictly increasing in `t`, first t=0, last t=1."

First observedMay 25, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations, it discloses the insertion location, regex-based binding validation, fast structured-error behavior, the orientation caveat, that it returns modified code plus diagnostics, and that it is side-effect-free. These details align with the annotations' readOnlyHint=false and destructiveHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured and front-loaded with the primary use case. It contains some redundancy with the schema, particularly around section constraints and binding types, but every major behavior is covered without excessive filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the description covers when to use it, what it inserts, where it inserts it, the result type, parameter constraints, validation behavior, orientation limitations, and side-effect profile. An output schema exists, so the return-value detail is not a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description largely restates what the schema already provides: binding types, strict t ordering, and the [0,1] span. It adds minor context about existing source variables and the resulting Shape, but this does not significantly raise the value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: insert a `variableSweep(spine, sections, opts?)` declaration into the .kcad.ts source before the last top-level return. It clearly distinguishes this from sibling tools by naming the target use case — an organic swept solid whose cross-section changes along its length.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It opens with an explicit trigger: 'Use this when you need an organic swept solid whose cross-section changes along its length' and gives concrete examples. However, it does not name alternative tools or state when not to use it, so it stops short of full routing guidance.

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

All kernelcad tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.