kernelCAD

Set Parameter

set_param

Idempotent

Use this when you need to edit a param() default value in a kernelCAD script. Returns the modified code as text plus diagnostics from re-evaluating the result. Caller persists the new code via standard file-write tools (this tool has no side effects). With preview: true it builds the edit in a scratch session instead and returns the diff_geometry summary plus the requirements-ledger and S1 binding diffs (which requirements flip, which margins shrink, which selectors moved or re-bound), without touching the active session, source, revision or caches. A preview whose revised build fails returns ok:false and no diff. Inspect after.requirementsOk to see whether the edit preserves declared intent; preview.ok only says the preview could be computed.

Input Schema

Name	Required	Description
`code`	Yes	The .kcad.ts source code.
`preview`	No	S6 edit preview: evaluate the edit in a scratch session and return geometry + requirements-ledger + S1 binding diffs. Writes nothing. Default false (the normal source-edit result).
`new_value`	Yes	The new default value. A number for a numeric param (e.g. 12.5), a string expression evaluated in the script (e.g. "width/2 + 3") or a choice/colour, or true/false for a boolean param.
`param_name`	Yes	The string literal name of the param (first arg to param()).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 31, 2026

changedInput schema / properties / new_value / description

Previous value: -"The new default value. Either a number for a numeric param (e.g. 12.5), or a string expression evaluated in the script (e.g. \"width/2 + 3\")."New value: +"The new default value. A number for a numeric param (e.g. 12.5), a string expression evaluated in the script (e.g. \"width/2 + 3\") or a choice/colour, or true/false for a boolean param."

changedInput schema / properties / new_value / examples

Previous value: -[
-  12.5,
-  "width/2 + 3"
-]New value: +[
+  12.5,
+  "width/2 + 3",
+  true
+]

changedInput schema / properties / new_value / oneOf

Previous value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "string"
-  }
-]New value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "boolean"
+  }
+]

Changed1 schema field changedOct 25, 2026

addedInput schema / properties / preview

Added value: +{
+  "description": "S6 edit preview: evaluate the edit in a scratch session and return geometry + requirements-ledger + S1 binding diffs. Writes nothing. Default false (the normal source-edit result).",
+  "type": "boolean"
+}

Changed2 schema fields changedOct 11, 2026

removedOutput schema / properties

Removed value: -{
-  "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"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "ok"
-]
```

Changed3 schema fields changedJul 18, 2026

changedInput schema / properties / new_value / description

Previous value: -"The new default value — number for numeric params, string for expressions."New value: +"The new default value. Either a number for a numeric param (e.g. 12.5), or a string expression evaluated in the script (e.g. \"width/2 + 3\")."

addedInput schema / properties / new_value / examples
```
Added value: +[
+  12.5,
+  "width/2 + 3"
+]
```

addedInput schema / properties / new_value / oneOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "string"
+  }
+]

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

AddedJun 13, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Discloses behavior annotations cannot: the caller must persist the returned code via file-write tools, diagnostics come from re-evaluating the result, preview runs in a scratch session touching no source/revision/caches, and after.requirementsOk means something different from preview.ok. The only friction is the claim 'this tool has no side effects' sitting uneasily with readOnlyHint=false, leaving it unclear whether the non-preview path mutates anything in-session.

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?

Front-loaded with the action, then returns, persistence responsibility, preview behavior, failure semantics and interpretation guidance in a logical order with zero filler sentences. It is dense and jargon-heavy (requirements-ledger, S1 binding diffs), which costs a point on readability but not on relevance.

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

Completeness4/5

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

Covers what a caller needs for a 4-parameter editing tool: input contract, return shape, side-effect boundary, and preview failure/interaction semantics. The remaining gap is that terms like requirements-ledger and S1 binding diffs are asserted without explanation, so an agent may know the tool is right but not how to interpret those diff payloads without another lookup.

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%, so the schema already documents code, param_name, new_value and preview. The description reinforces preview semantics (scratch build, what diffs are returned, writes nothing) but adds nothing about the other three parameters beyond what the schema says; baseline 3 applies.

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

Purpose5/5

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

States a precise verb+resource: edit a param() default value inside a kernelCAD script, and says exactly what it returns (modified code plus diagnostics). No sibling tool shares this scope, so an agent can distinguish it without inspecting schemas.

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?

Gives a clear trigger ('Use this when you need to edit a param() default value') and explicit conditional guidance for preview:true versus the default false path, including that a failed preview returns ok:false and no diff. It does not name an alternative sibling or state when not to use it, so it stops short of the top mark.

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

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.