Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

save_feature

Saves a new versioned mechanical feature or appends changes to an existing one, letting you track feature revisions and reuse design details in Kiln Pro.

Instructions

Save a new versioned mechanical feature (or append to existing).

Needs Kiln Pro.

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": {
      "name": "<name>",
      "feature_kind": "<feature_kind>",
      "parameters": "<parameters>",
      "target_kind": "<target_kind>"
    },
    "name": "save_feature"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesDisplay name (e.g. ``"handle-fillet"``).
notesNoFreeform operator note. Default: "".
metadataNoCaller-specific JSON blob.
design_idNoAssociated design id, or ``None`` for portfolio-wide reusable features.
feature_idNoExisting feature id to append to; omit for a fresh feature.
parametersYesKind-specific dict (e.g. chamfer → ``{"offset_mm": 1.5}``).
target_kindYesOne of ``edge``, ``face``, ``vertex``, ``volumetric``.
target_specNoWhere on the host mesh the feature applies, as a dict stored as given (e.g. ``{"face_ids": [12, 13]}`` for a face target, or for a ``part`` the attachment spec from ``list_feature_kinds``). Omit it when the kind needs no target.
feature_kindYesOne of ``chamfer``, ``fillet``, ``pocket``, ``hole``, ``boss``, ``rib``, ``screw_hole_pattern``, ``custom_scad``, or ``part`` (a reusable attachable component — a hat / clip / bracket — carrying its own sub-model via ``openscad_module`` / an imported mesh asset; attach it onto a host design with ``attach_part_feature``). Use ``list_feature_kinds`` to discover the param spec.
parent_feature_version_idNoExplicit parent version this one iterates from; auto-inferred from HEAD when ``feature_id`` is supplied without a parent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv1.5.1
    • addedInput schema / properties / design_id / description
      Added value: +"Associated design id, or ``None`` for portfolio-wide reusable features."
    • addedInput schema / properties / feature_id / description
      Added value: +"Existing feature id to append to; omit for a fresh feature."
    • addedInput schema / properties / feature_kind / description
      Added value: +"One of ``chamfer``, ``fillet``, ``pocket``, ``hole``, ``boss``, ``rib``, ``screw_hole_pattern``, ``custom_scad``, or ``part`` (a reusable attachable component — a hat / clip / bracket — carrying its own sub-model via ``openscad_module`` / an imported mesh asset; attach it onto a host design with ``attach_part_feature``).  Use ``list_feature_kinds`` to discover the param spec."
    • addedInput schema / properties / metadata / description
      Added value: +"Caller-specific JSON blob."
    • addedInput schema / properties / name / description
      Added value: +"Display name (e.g. ``\"handle-fillet\"``)."
    • changedInput schema / properties / notes / description
      Previous value: -"Default: \"\"."New value: +"Freeform operator note. Default: \"\"."
    • addedInput schema / properties / parameters / description
      Added value: +"Kind-specific dict (e.g. chamfer → ``{\"offset_mm\": 1.5}``)."
    • addedInput schema / properties / parent_feature_version_id / description
      Added value: +"Explicit parent version this one iterates from; auto-inferred from HEAD when ``feature_id`` is supplied without a parent."
    • addedInput schema / properties / target_kind / description
      Added value: +"One of ``edge``, ``face``, ``vertex``, ``volumetric``."
    • addedInput schema / properties / target_spec / description
      Added value: +"Where on the host mesh the feature applies, as a dict stored as given (e.g. ``{\"face_ids\": [12, 13]}`` for a face target, or for a ``part`` the attachment spec from ``list_feature_kinds``).  Omit it when the kind needs no target."
  2. Addedv1.5.0

TDQS

B3.2/5.0
Behavior2/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is already known. The description adds two useful non-annotation facts — results are 'versioned' and the call is gated on Kiln Pro entitlement — but it does not say what happens when the Pro gate fails, whether saving moves HEAD, or what it returns.

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?

Two short, front-loaded sentences with no filler; the primary behavior comes first and the prerequisite second. The 'Needs Kiln Pro.' fragment is terse to the point of being unexplained, but it does not waste space.

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

Completeness3/5

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

For a 10-parameter mutation tool with nested objects and no output schema, the description should say what the caller gets back (feature id / version id) and how appending interacts with parent_feature_version_id before HEAD moves. The entitlement note is helpful, but the return contract and versioning side effects are left unstated.

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 every parameter including feature_kind, target_kind, and parent_feature_version_id is already documented with examples and enum-like values. The description only reinforces the create-vs-append distinction supplied by feature_id, adding little beyond the schema, which is the expected baseline.

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 versioned mechanical feature (or append to existing).' The parenthetical distinguishes the two modes (create vs. append) so an agent can tell it apart from read-side siblings like list_features or get_feature without opening the schema. It stops short of naming a concrete alternative for branch/release operations.

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?

The description signals the two valid modes (fresh save vs. append) and a hard prerequisite ('Needs Kiln Pro'), which is real routing information. It gives no explicit when-to-use vs. alternatives guidance, such as pointing to list_feature_kinds before composing a kind-specific payload or to cloud_push_feature_branch for publishing.

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