Skip to main content
Glama

save_design_version

Save a new version of a parametric design, automatically compute a diff from the previous version, and persist a versioned recipe for change tracking.

Instructions

Save a new version of a parametric design.

        Automatically computes a unified diff from the previous version,
        increments the version number, and persists a versioned recipe
        sidecar (``~/.kiln/designs/<design_id>/.kiln_recipe.vN.json``).

        On Kiln Pro a save also fingerprints the mesh, warns when features
        are lost between versions, and writes a ``.kiln.json`` provenance
        sidecar that travels with the STL.

        Args:
            design_id: Identifier grouping versions of the same design.
            scad_source: Full OpenSCAD source code for this version.
            prompt: The natural-language prompt that produced this version.
            parameters: Parametric values used for generation.
            notes: Free-text notes for this version.
            provenance: Context on how this version was created.
                Recommended keys: ``tools_used``, ``change_summary``,
                ``source_files``.
            stl_path: Path to the output STL file.  When given, the
                version's mesh is fingerprinted and the reply warns if
                features were lost since the parent version.
            parent_version_id: Which earlier version the mesh
                fingerprint is compared against.  Omitted, the most
                recent existing version is the parent (and the source
                diff always uses that one).
            brief_id: Optional saved-goal id from ``design_session``.
                When supplied, the new version's recipe records the
                link so the audit's "matches what you asked for" gate,
                the brief failure_history wiring, and the
                ``compare_design_versions`` intent diff all join back
                to the goal.  When omitted, an earlier version's
                ``brief_id`` (read from the parent recipe) is
                inherited automatically.
            intent_hash: Optional content hash of the brief's derived
                intent payload, paired with ``brief_id``.  Same
                inheritance fall-back as ``brief_id``.

        Returns:
            The saved version record including version number, diff, and
            parent information.  Pro users also get provenance,
            mesh_fingerprint, and mesh_diff with regression warnings.
        

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "design_id": "<design_id>",
      "scad_source": "<scad_source>"
    },
    "name": "save_design_version"
  }
}

Input Schema

NameRequiredDescriptionDefault
notesNoFree-text notes for this version. Default: "".
promptNoThe natural-language prompt that produced this version. Default: "".
brief_idNoOptional saved-goal id from ``design_session``. When supplied, the new version's recipe records the link so the audit's "matches what you asked for" gate, the brief failure_history wiring, and the ``compare_design_versions`` intent diff all join back to the goal. When omitted, an earlier version's ``brief_id`` (read from the parent recipe) is inherited automatically. Default: "".
stl_pathNoPath to the output STL file. When given, the version's mesh is fingerprinted and the reply warns if features were lost since the parent version. Default: "".
design_idYesIdentifier grouping versions of the same design.
parametersNoParametric values used for generation.
provenanceNoContext on how this version was created. Recommended keys: ``tools_used``, ``change_summary``, ``source_files``.
intent_hashNoOptional content hash of the brief's derived intent payload, paired with ``brief_id``. Same inheritance fall-back as ``brief_id``. Default: "".
scad_sourceYesFull OpenSCAD source code for this version.
parent_version_idNoWhich earlier version the mesh fingerprint is compared against. Omitted, the most recent existing version is the parent (and the source diff always uses that one). Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv1.5.1
    • changedInput schema / properties / brief_id / description
      Previous value: -"Default: \"\"."New value: +"Optional saved-goal id from ``design_session``. When supplied, the new version's recipe records the link so the audit's \"matches what you asked for\" gate, the brief failure_history wiring, and the ``compare_design_versions`` intent diff all join back to the goal.  When omitted, an earlier version's ``brief_id`` (read from the parent recipe) is inherited automatically. Default: \"\"."
    • addedInput schema / properties / design_id / description
      Added value: +"Identifier grouping versions of the same design."
    • changedInput schema / properties / intent_hash / description
      Previous value: -"Default: \"\"."New value: +"Optional content hash of the brief's derived intent payload, paired with ``brief_id``.  Same inheritance fall-back as ``brief_id``. Default: \"\"."
    • changedInput schema / properties / notes / description
      Previous value: -"Default: \"\"."New value: +"Free-text notes for this version. Default: \"\"."
    • addedInput schema / properties / parameters / description
      Added value: +"Parametric values used for generation."
    • changedInput schema / properties / parent_version_id / description
      Previous value: -"Default: \"\"."New value: +"Which earlier version the mesh fingerprint is compared against.  Omitted, the most recent existing version is the parent (and the source diff always uses that one). Default: \"\"."
    • changedInput schema / properties / prompt / description
      Previous value: -"Default: \"\"."New value: +"The natural-language prompt that produced this version. Default: \"\"."
    • addedInput schema / properties / provenance / description
      Added value: +"Context on how this version was created. Recommended keys: ``tools_used``, ``change_summary``, ``source_files``."
    • addedInput schema / properties / scad_source / description
      Added value: +"Full OpenSCAD source code for this version."
    • changedInput schema / properties / stl_path / description
      Previous value: -"Default: \"\"."New value: +"Path to the output STL file.  When given, the version's mesh is fingerprinted and the reply warns if features were lost since the parent version. Default: \"\"."
  2. Changed14 schema fields changedv1.5.0
    • removedInput schema / properties / brief_id / default
      Removed value: -""
    • addedInput schema / properties / brief_id / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / intent_hash / default
      Removed value: -""
    • addedInput schema / properties / intent_hash / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / notes / default
      Removed value: -""
    • addedInput schema / properties / notes / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / parameters / default
      Removed value: -null
    • removedInput schema / properties / parent_version_id / default
      Removed value: -""
    • addedInput schema / properties / parent_version_id / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / prompt / default
      Removed value: -""
    • addedInput schema / properties / prompt / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / provenance / default
      Removed value: -null
    • removedInput schema / properties / stl_path / default
      Removed value: -""
    • addedInput schema / properties / stl_path / description
      Added value: +"Default: \"\"."
  3. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only say it is a non-read-only, non-destructive, closed-world write. The description adds substantive behavior: a unified diff against the previous version, automatic version increment, a filesystem sidecar at ~/.kiln/designs/<design_id>/.kiln_recipe.vN.json, and tier-dependent Pro fingerprinting and provenance writes. It never explains what happens on a locked design or whether parent brief_id inheritance can be overridden with an empty string, which keeps it from a 5.

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

Conciseness3/5

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

The opening paragraphs are well front-loaded and informative, but the Args section duplicates schema text for every parameter, inflating length without adding information. The Returns block is useful and concise, but overall the description roughly doubles the necessary size.

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?

There is no output schema, and the description compensates with a Returns section covering version number, diff, parent info, and Pro-only provenance and mesh fields. Combined with sidecar path disclosure and the tier split, an agent has most of what it needs, with the main gap being error and locking behavior.

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 description coverage is 100%, so the schema already documents all ten parameters. The Args block largely restates those schema descriptions verbatim (brief_id, stl_path, parent_version_id, intent_hash), adding little meaning beyond what is already structured, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ('Save a new version of a parametric design') plus the concrete artifact it writes. It does not explicitly distinguish itself from neighboring version tools such as rollback_design_version, get_design_version, or save_feature, so it stops 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.

Usage Guidelines3/5

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

Usage is only implied: you call this when you have a full OpenSCAD source for a new version. There is no explicit when-not-to-use guidance, no mention of how it relates to rollback_design_version or design_session, and no stated prerequisites such as tier requirements for the Pro-only behaviors it describes.

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

Deploy Server

Other Tools