Skip to main content
Glama

kernelcad

by com.kernelcad
OverviewDiscussionsAdmin

Evaluate CAD Script

evaluate_script
Read-only

Use this when you need to run a script and check it compiles. Run a kernelCAD .kcad.ts script and report pass/fail + feature count + diagnostics. When the scene is assembly-built (assembly().part(...) → .model()/.solvedModel()), also returns a parts summary { count, names } AND runs the mechanism-truth gate by default: the mechanism field reports real/broken/unverified and a broken mechanism (self-collision, fastened drift, dof-mismatch) makes ok:false with the failures in diagnostics. Pass { skipMechanismCheck: true } to opt out. Pass either { file: "" } or { code: "" }. Set { dryRun: true } for fast validation while iterating: transpile + capture + capture-light checks WITHOUT OCCT lowering, DFM gates, or meshing — milliseconds instead of seconds (100x+ on boolean/fillet-heavy scripts). A dry run catches script throws, capture-time API misuse, and assembly validity-gate failures, but NOT lowering failures or dfmSpec diagnostics; it leaves the active session untouched, so finish with a full (non-dry) evaluate_script before using session-dependent tools.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoInline kernelCAD script source.
fileNoPath to a .kcad.ts script file.
dryRunNoFast validation only: skip OCCT lowering, DFM gates, and meshing. Does not set or clear the active session.
skipMechanismCheckNoOpt out of the default mechanism-truth gate. By default a full evaluation of an assembly-built scene runs checkMechanismTruth and returns a `mechanism` verdict (real/broken/unverified); a broken mechanism makes ok:false. Set true to skip the sweep entirely (no `mechanism` field, no cost). Ignored for dryRun and non-assembly scripts.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesWhether the script compiled and lowered cleanly.
partsNoAssembly parts summary { count, names } when the scene is assembly-built.
dryRunNoTrue when the result came from a fast dry run.
mechanismNoMechanism-truth verdict for an assembly-built scene (default-on; omitted for dryRun, non-assembly, or skipMechanismCheck:true). 'broken' makes ok:false; 'unverified' keeps ok and surfaces a loud budget diagnostic.
diagnosticsYes
featureCountYesNumber of features captured by the script.
featureHealthNoPer-feature health degradations — ONLY features that fell back to a passthrough (warning) or failed to lower (error). Empty when every feature is healthy. Surfaces which feature degraded even when ok is true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / skipMechanismCheck
      Added value: +{
+  "description": "Opt out of the default mechanism-truth gate. By default a full evaluation of an assembly-built scene runs checkMechanismTruth and returns a `mechanism` verdict (real/broken/unverified); a broken mechanism makes ok:false. Set true to skip the sweep entirely (no `mechanism` field, no cost). Ignored for dryRun and non-assembly scripts.",
+  "type": "boolean"
+}
    • addedOutput schema / properties / featureHealth
      Added value: +{
+  "description": "Per-feature health degradations — ONLY features that fell back to a passthrough (warning) or failed to lower (error). Empty when every feature is healthy. Surfaces which feature degraded even when ok is true.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "featureId": {
+        "type": "string"
+      },
+      "status": {
+        "enum": [
+          "warning",
+          "error"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "featureId",
+      "status"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • addedOutput schema / properties / mechanism
      Added value: +{
+  "description": "Mechanism-truth verdict for an assembly-built scene (default-on; omitted for dryRun, non-assembly, or skipMechanismCheck:true). 'broken' makes ok:false; 'unverified' keeps ok and surfaces a loud budget diagnostic.",
+  "enum": [
+    "real",
+    "broken",
+    "unverified"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "diagnostics": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "dryRun": {
+      "description": "True when the result came from a fast dry run.",
+      "type": "boolean"
+    },
+    "featureCount": {
+      "description": "Number of features captured by the script.",
+      "type": "number"
+    },
+    "ok": {
+      "description": "Whether the script compiled and lowered cleanly.",
+      "type": "boolean"
+    },
+    "parts": {
+      "additionalProperties": true,
+      "description": "Assembly parts summary { count, names } when the scene is assembly-built.",
+      "type": "object"
+    }
+  },
+  "required": [
+    "ok",
+    "featureCount",
+    "diagnostics"
+  ],
+  "type": "object"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / dryRun
      Added value: +{
+  "description": "Fast validation only: skip OCCT lowering, DFM gates, and meshing. Does not set or clear the active session.",
+  "type": "boolean"
+}
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only/non-destructive safety, and the description adds substantial behavioral detail: dryRun skips OCCT lowering, DFM gates, and meshing; it leaves the active session untouched; the default mechanism-truth gate can force ok:false; and skipMechanismCheck is ignored in dry-run/non-assembly cases. This goes well beyond annotation coverage and contradicts nothing.

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

Conciseness5/5

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

The description is dense but every clause earns its place: trigger, output contract, assembly caveat, input modes, dry-run tradeoffs, and follow-up workflow. It is front-loaded with the most decision-relevant information and contains no 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?

For a tool with multiple modes, an output schema, and assembly-specific behavior, the description covers when to call it, how to invoke it, what dry-run sacrifices, what the mechanism gate does, and what to do afterward. The output schema handles return-value detail, so nothing essential is missing.

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

Parameters4/5

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

The schema already covers all four parameters at 100%, so the baseline is 3. The description adds value by stating the file/code alternatives explicitly and explaining the practical consequences of dryRun — millisecond-level fast iteration, what it can and cannot catch — beyond the schema's brief field descriptions.

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

Purpose5/5

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

The description names a specific verb and resource — 'run a kernelCAD .kcad.ts script' — and enumerates concrete outputs: pass/fail, feature count, diagnostics, and an assembly-scene mechanism verdict. This scope clearly separates it from generic siblings like verify, inspect, or query.

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 to run a script and check it compiles') and includes workflow guidance to finish with a non-dry run before session-dependent tools. It does not explicitly name sibling alternatives or exclusion conditions, so it stops short of a 5.

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

All kernelcad toolsInspect
Try in Browser
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.

Resources