Skip to main content
Glama

sign_design_release

Sign and persist an immutable named release of a design version to preserve provenance and mark it as distributable.

Instructions

Sign and persist an immutable named release of a version.

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": {
      "design_id": "<design_id>",
      "version_id": "<version_id>",
      "name": "<name>"
    },
    "name": "sign_design_release"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesThe release name, e.g. ``1.0.0`` (semver), ``2026.4.16`` (calendar) or any other text (arbitrary). A name already used for this design is refused.
ancestryNoOptional echo of the version's lineage, as version ids from root to this version. Omit it to sign the recorded lineage; a list that disagrees is refused (``ANCESTRY_MISMATCH``).
outcomesNoOptional echo of the print outcomes recorded against the version. Omit it to sign the record; a list that disagrees is refused (``OUTCOMES_MISMATCH``).
design_idYesId of the design the release belongs to.
signed_byNoWho signs, recorded as the signer. Omit it to use the caller's own identity: on Kiln's servers the signed-in account (a different name is refused), locally the declared operator or the computer's user name.
provenanceNoYour own metadata to carry in the signed manifest. Keys Kiln writes itself (``assembly_manual``, ``spec_receipt``, ``reference_grade``) are dropped and named in ``discarded_provenance_keys``.
version_idYesId of the design version being released. Its geometry, lineage and outcomes are read from Kiln's record.
branch_nameNoName of the branch the version was released from, recorded in the manifest. Omit it to record none.
assembly_jsonNoThe assembly state, as returned by ``create_assembly`` / ``add_assembly_part`` / ``add_assembly_interface`` (JSON text or the object). When given, an assembly manual is made and its hash signed into the release; when the manual cannot be made for this caller the release signs without one and ``assembly_manual`` says why. Omit it for no manual.
manual_brandingNoHow Kiln's mark appears on the manual: ``"prominent"``, ``"subtle"``, ``"white_label"`` or ``"auto"``. Omit it for ``auto``, which follows the caller's plan. Used only with ``assembly_json``.
manual_languagesNoOrdered language codes for the manual, e.g. ``["en", "de"]``; each language gets its own parts list and steps in one PDF. Omit it for one section in English. Used only with ``assembly_json``.
mesh_fingerprintNoOptional echo of the version's mesh fingerprint. Omit it to sign Kiln's own reading; a value that disagrees is refused (``FINGERPRINT_MISMATCH``).
manual_co_brand_nameNoA maker name to show on the manual's cover in place of Kiln's line, where the plan permits co-branding; dropped otherwise. Used only with ``assembly_json``.
manual_cover_languageNoLanguage code for the manual's cover. Omit it to use the first of ``manual_languages`` (or English). Used only with ``assembly_json``.
manual_design_name_translationsNoLanguage code to product name, e.g. ``{"de": "Gelenkleuchte"}``, used as the cover title in that language; languages without one keep ``name``. Used only with ``assembly_json``.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv1.5.1
    • addedInput schema / properties / ancestry / description
      Added value: +"Optional echo of the version's lineage, as version ids from root to this version.  Omit it to sign the recorded lineage; a list that disagrees is refused (``ANCESTRY_MISMATCH``)."
    • addedInput schema / properties / assembly_json / description
      Added value: +"The assembly state, as returned by ``create_assembly`` / ``add_assembly_part`` / ``add_assembly_interface`` (JSON text or the object).  When given, an assembly manual is made and its hash signed into the release; when the manual cannot be made for this caller the release signs without one and ``assembly_manual`` says why.  Omit it for no manual."
    • addedInput schema / properties / branch_name / description
      Added value: +"Name of the branch the version was released from, recorded in the manifest.  Omit it to record none."
    • addedInput schema / properties / design_id / description
      Added value: +"Id of the design the release belongs to."
    • addedInput schema / properties / manual_branding / description
      Added value: +"How Kiln's mark appears on the manual: ``\"prominent\"``, ``\"subtle\"``, ``\"white_label\"`` or ``\"auto\"``. Omit it for ``auto``, which follows the caller's plan.  Used only with ``assembly_json``."
    • addedInput schema / properties / manual_co_brand_name / description
      Added value: +"A maker name to show on the manual's cover in place of Kiln's line, where the plan permits co-branding; dropped otherwise.  Used only with ``assembly_json``."
    • addedInput schema / properties / manual_cover_language / description
      Added value: +"Language code for the manual's cover. Omit it to use the first of ``manual_languages`` (or English).  Used only with ``assembly_json``."
    • addedInput schema / properties / manual_design_name_translations / description
      Added value: +"Language code to product name, e.g. ``{\"de\": \"Gelenkleuchte\"}``, used as the cover title in that language; languages without one keep ``name``.  Used only with ``assembly_json``."
    • addedInput schema / properties / manual_languages / description
      Added value: +"Ordered language codes for the manual, e.g. ``[\"en\", \"de\"]``; each language gets its own parts list and steps in one PDF.  Omit it for one section in English.  Used only with ``assembly_json``."
    • addedInput schema / properties / mesh_fingerprint / description
      Added value: +"Optional echo of the version's mesh fingerprint.  Omit it to sign Kiln's own reading; a value that disagrees is refused (``FINGERPRINT_MISMATCH``)."
    • addedInput schema / properties / name / description
      Added value: +"The release name, e.g. ``1.0.0`` (semver), ``2026.4.16`` (calendar) or any other text (arbitrary).  A name already used for this design is refused."
    • addedInput schema / properties / outcomes / description
      Added value: +"Optional echo of the print outcomes recorded against the version.  Omit it to sign the record; a list that disagrees is refused (``OUTCOMES_MISMATCH``)."
    • addedInput schema / properties / provenance / description
      Added value: +"Your own metadata to carry in the signed manifest. Keys Kiln writes itself (``assembly_manual``, ``spec_receipt``, ``reference_grade``) are dropped and named in ``discarded_provenance_keys``."
    • addedInput schema / properties / signed_by / description
      Added value: +"Who signs, recorded as the signer.  Omit it to use the caller's own identity: on Kiln's servers the signed-in account (a different name is refused), locally the declared operator or the computer's user name."
    • addedInput schema / properties / version_id / description
      Added value: +"Id of the design version being released.  Its geometry, lineage and outcomes are read from Kiln's record."
  2. Addedv1.5.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare this is a write with destructiveHint=false and openWorldHint=false. The description adds two things annotations cannot: the release is immutable once signed, and the action is gated behind the Kiln Pro entitlement. It says nothing about failure modes (duplicate name refusal, mismatch refusals) or what the caller receives back, which is the larger behavioral gap.

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 sentences, with the action front-loaded and the entitlement constraint second. Nothing is wasted, but for a 15-parameter mutation the brevity edges toward under-specification rather than tightness.

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?

The schema is rich and self-documenting, and the description covers the entitlement and immutability angle. It is still thin for a high-stakes signing operation: it omits that a release manifest is produced, that signing can be refused on name collision or ancestry/outcome/fingerprint mismatch, and how this differs from the sibling signing tools.

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 explains every one of the 15 parameters, including the optional echo parameters and their refusal codes. The description adds no parameter meaning at all, 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: sign and persist an immutable named release of a version. That is clearly distinct from list_design_releases and retire_design_release, but it does not distinguish itself from the near-identical siblings sign_feature_release and sign_decoration_preset_release, which an agent must tell apart by name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The only guidance is the prerequisite "Needs Kiln Pro". There is no statement of when to sign a release versus when to verify_design_release, retire_design_release, or push to cloud, and no mention of which branch or version state makes signing appropriate.

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