kernelcad

Project Curve

project_curve

Use this when you need to wrap a 2D closed curve onto a 3D face. Insert a <shape>.projectCurve({ source, face, scaleMode? }) chained call into a kernelCAD script. The source is the structured { kind: "sketchCommands", commands: [...] } wire format the runtime API accepts. Wraps the curve onto the face along the face normal; pair with .extrude(d) / .cut(...) for raised or engraved logos on curved bodies. Open-wire projection (asEdge: true) is not implemented and is rejected at edit time. Side-effect-free; returns modified code plus diagnostics.

Input Schema

TableJSON Schema

Name	Required	Description
`code`	Yes	The .kcad.ts source code.
`face`	Yes	Target face — canonical name or label.
`asEdge`	No	Open-wire (edge) projection. NOT IMPLEMENTED — rejected at edit time. Use a closed-curve projection (omit asEdge).
`bindAs`	No	Optional local variable name; emits `const <bindAs> = <target>.projectCurve(...);`.
`target`	Yes	Variable name of the Shape to chain onto.
`commands`	Yes	Closed 2D path to wrap onto the face, as plain-number commands. Must start with a `moveTo` and end with a `close` (e.g. [{kind:"moveTo",x:0,y:0},{kind:"lineTo",x:2,y:0},{kind:"lineTo",x:2,y:2},{kind:"close"}]).
`scaleMode`	No	Drawing.sketchOnFace scaling mode. Default original.

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.

Changed4 schema fields changedSep 21, 2026

changedInput schema / properties / asEdge / description

Previous value: -"Project as an open edge instead of a closed face-bound sketch. Currently deferred."New value: +"Open-wire (edge) projection. NOT IMPLEMENTED — rejected at edit time. Use a closed-curve projection (omit asEdge)."

addedInput schema / properties / commands

Added value: +{
+  "description": "Closed 2D path to wrap onto the face, as plain-number commands. Must start with a `moveTo` and end with a `close` (e.g. [{kind:\"moveTo\",x:0,y:0},{kind:\"lineTo\",x:2,y:0},{kind:\"lineTo\",x:2,y:2},{kind:\"close\"}]).",
+  "items": {
+    "properties": {
+      "kind": {
+        "enum": [
+          "moveTo",
+          "lineTo",
+          "close"
+        ],
+        "type": "string"
+      },
+      "x": {
+        "type": "number"
+      },
+      "y": {
+        "type": "number"
+      }
+    },
+    "required": [
+      "kind"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

removedInput schema / properties / curveExpression

Removed value: -{
-  "description": "JS expression returning a closed sketch (e.g. `path().moveTo(0,0).lineTo(2,0).lineTo(2,2).close().build()`). Inserted verbatim as the `curve:` field.",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "code",
-  "target",
-  "curveExpression",
-  "face"
-]New value: +[
+  "code",
+  "target",
+  "commands",
+  "face"
+]

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"
+}

First observedMay 25, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Discloses the side-effect-free nature, the return shape ('modified code plus diagnostics'), the rejection of `asEdge: true`, and the face-normal wrapping behavior. This goes well beyond the annotations, which only set readOnly/destructive hints.

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

Conciseness5/5

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

The description is four purposeful sentences with the use case up front. Every sentence adds a distinct fact—entry point, source format, behavior/pairing, limitation, and side-effect profile—with no repetition of schema boilerplate.

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

Completeness5/5

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

For a code-rewriting tool with seven parameters, this description covers the when, the how, the return type, the side-effect profile, and a key unsupported edge. The rich schema and output schema fill remaining parameter-level details, so nothing an agent needs for correct invocation is missing.

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

Parameters4/5

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

The input schema already documents every parameter at 100% coverage. The description adds useful context by explaining the underlying `source` wire format and clarifying that `commands` must form a closed path, which is extra confidence beyond the schema's enum and example.

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?

Opens with a concrete action—'wrap a 2D closed curve onto a 3D face'—and names the exact API call (`<shape>.projectCurve`). The 'chained call into a kernelCAD script' and 'returns modified code plus diagnostics' description separates it from sibling modeling tools like add_curve or add_surface.

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

Usage Guidelines5/5

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

Explicitly says 'Use this when you need...' and gives a clear non-goal: open-wire projection with `asEdge: true` is not implemented and rejected at edit time. It even provides the composition pattern with `.extrude(d)` / `.cut(...)`, so the agent knows when and how to chain it.

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.