Skip to main content
Glama

save_design_version

Save a new version of a parametric design with automatic diff computation and version increment. Supports optional provenance, STL fingerprinting, and brief linking for audit trails.

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``).

        **Upgrade to Kiln Pro** for automatic mesh fingerprinting,
        regression detection (warns when features are lost between
        versions), and ``.kiln.json`` sidecar provenance files that
        travel with your STLs.

        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``.  (Pro: auto-enriched with mesh
                fingerprinting and regression detection.)
            stl_path: Path to the output STL file.  (Pro: auto-computes
                a geometric fingerprint and warns if features were
                lost from the parent version.)
            parent_version_id: Unused in this implementation; kept for
                backward compatibility.  The parent is always the most
                recent existing version.
            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.
        

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNo
promptNo
brief_idNo
stl_pathNo
design_idYes
parametersNo
provenanceNo
intent_hashNo
scad_sourceYes
parent_version_idNo
Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses automatic diff computation, version increment, sidecar persistence, inheritance of brief_id/intent_hash, and parent_version_id being unused. Lacks information on required permissions or side effects like overwriting.

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?

Well-structured with sections for description, Args, and Returns. However, includes promotional text about Kiln Pro, which adds length without essential guidance. Still organized and front-loaded with core purpose.

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?

Comprehensive for a tool with 10 parameters, no output schema, and no annotations. Explains behavior, inheritance, and file paths. Lacks error handling or prerequisites, but generally complete for agent invocation.

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

Parameters5/5

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

Schema coverage is 0%, but the description's 'Args' section thoroughly explains all 10 parameters, including recommended keys for provenance and inheritance behavior for brief_id and intent_hash. Adds significant meaning beyond the parameter names.

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?

Clear verb 'Save a new version of a parametric design' with specific details about diff computation, version increment, and persistence. Distinguishes from siblings like list_design_versions or diff_design_versions through its action of saving a new version.

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?

No explicit when-to-use or when-not-to-use guidance. Usage is implied from the purpose, but no alternatives or conditions are stated. The description focuses on functionality rather than decision context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/codeofaxel/kiln'

If you have feedback or need assistance with the MCP directory API, please join our Discord server