Skip to main content
Glama

design_session

Destructive

Turn a plain-English idea into a 3D-printable model, resolve vague requests with clarifying questions, and track each version under a goal for later revisions.

Instructions

Make, design or create any physical object — a part, a bracket, a box, a holder, a gift — as a 3D model ready to print. Describe it in plain English: a specific request goes straight to generate, a vague one gets a quick question or two. Kiln builds the STL from the OpenSCAD you write (scad_code) and reports which design checks it passes. It saves the request as a goal, so later versions and parts made with Kiln's other make tools can be kept together under its goal_id. Verbs: start, update, save (or commit), generate (or make), join.

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": {
      "verb": "<verb>"
    },
    "name": "design_session"
  }
}

Input Schema

NameRequiredDescriptionDefault
ideaNoWhat the person wants to make, in their words. Required for ``start``; ignored by the other verbs. Default: "".
verbYesThe move to make: ``start``, ``update``, ``save`` (or ``commit``), ``generate`` (or ``make``) and ``join``; any other word is refused.
answersNoReplies to the goal's open questions, mapping each question's text to the answer. Read by ``update``, ``save`` and ``generate``; answers given on ``save`` or ``generate`` are named back under ``assumed``.
goal_idNoThe goal ``start`` returned. Required for every verb but ``start``, and for recording numbers, pictures or refusals on a later call. Default: "".
materialNoFor ``start``: the material the person has in mind, such as ``PLA``. Empty means none was named. Default: "".
made_withNoFor ``join``: where that model came from, as ``{kind, by}`` plus, for a download, its ``name``, ``creator``, ``license`` and ``url``; kept beside the version. Optional.
mesh_pathNoFor ``join``: the model file made somewhere else to add to the goal as its next version. Default: "".
scad_codeNoFor ``generate``: the OpenSCAD source to compile and check. Empty asks a configured cloud backend, or hands back the design details for you to write it. Default: "".
spec_numbersNoDimensions settled in conversation, one entry each, with ``label``, ``measurement`` (``bbox_x`` / ``bbox_y`` / ``bbox_z`` / ``volume_mm3`` / ``hole_count`` / ``min_hole_diameter``, or a name Kiln will learn to measure), ``value``, ``origin`` (``"user_stated"`` or ``"kiln_derived"``) and ``why`` (one plain sentence); ``tolerance`` and ``stated_text`` optional. Works with every verb; a later entry with the same label replaces the earlier one.
artifact_typeNoThe kind of thing being saved: ``design`` (the default), ``feature`` or ``decoration``, stamped on the goal. Default: "design".
edited_promptNoFor ``generate`` without ``scad_code`` only: words to hand back in place of the request Kiln builds from the goal. Ignored when ``scad_code`` is given, which is every OpenSCAD make.
target_size_mmNoFor ``start``: a size hint in millimetres, kept with the goal; it does not answer the sizing question on its own.
decided_againstNoWhat the person turned down, as a list of ``{what, why}`` entries kept on the goal; ``{what, withdrawn: true}`` takes one off the list.
material_changeNoFor ``update``, ``save`` and ``generate``: the filament the goal's part is made in now, as ``{material, why, decided_by, printer_model}``. Only ``material`` is required; ``why`` is why the old filament was set aside, ``decided_by`` is ``"person"`` when they chose it or ``"agent"`` when you did, and ``printer_model`` the printer it is printed on. The goal's old filament stays on its history.
reference_imagesNoA picture the person showed you: an image file path, or a list of them. Kept on the goal, so every later ``generate`` is checked against it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changedv1.5.1
    • addedInput schema / properties / answers / description
      Added value: +"Replies to the goal's open questions, mapping each question's text to the answer.  Read by ``update``, ``save`` and ``generate``; answers given on ``save`` or ``generate`` are named back under ``assumed``."
    • changedInput schema / properties / artifact_type / description
      Previous value: -"Default: \"design\"."New value: +"The kind of thing being saved: ``design`` (the default), ``feature`` or ``decoration``, stamped on the goal. Default: \"design\"."
    • addedInput schema / properties / decided_against / description
      Added value: +"What the person turned down, as a list of ``{what, why}`` entries kept on the goal; ``{what, withdrawn: true}`` takes one off the list."
    • addedInput schema / properties / edited_prompt
      Added value: +{
      +  "description": "For ``generate`` without ``scad_code`` only: words to hand back in place of the request Kiln builds from the goal.  Ignored when ``scad_code`` is given, which is every OpenSCAD make.",
      +  "title": "Edited Prompt",
      +  "type": "string"
      +}
    • changedInput schema / properties / goal_id / description
      Previous value: -"Default: \"\"."New value: +"The goal ``start`` returned.  Required for every verb but ``start``, and for recording numbers, pictures or refusals on a later call. Default: \"\"."
    • changedInput schema / properties / idea / description
      Previous value: -"Default: \"\"."New value: +"What the person wants to make, in their words.  Required for ``start``; ignored by the other verbs. Default: \"\"."
    • addedInput schema / properties / made_with
      Added value: +{
      +  "additionalProperties": true,
      +  "description": "For ``join``: where that model came from, as ``{kind, by}`` plus, for a download, its ``name``, ``creator``, ``license`` and ``url``; kept beside the version.  Optional.",
      +  "title": "Made With",
      +  "type": "object"
      +}
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"\"."New value: +"For ``start``: the material the person has in mind, such as ``PLA``.  Empty means none was named. Default: \"\"."
    • addedInput schema / properties / material_change
      Added value: +{
      +  "additionalProperties": true,
      +  "description": "For ``update``, ``save`` and ``generate``: the filament the goal's part is made in now, as ``{material, why, decided_by, printer_model}``.  Only ``material`` is required; ``why`` is why the old filament was set aside, ``decided_by`` is ``\"person\"`` when they chose it or ``\"agent\"`` when you did, and ``printer_model`` the printer it is printed on.  The goal's old filament stays on its history.",
      +  "title": "Material Change",
      +  "type": "object"
      +}
    • addedInput schema / properties / mesh_path
      Added value: +{
      +  "description": "For ``join``: the model file made somewhere else to add to the goal as its next version. Default: \"\".",
      +  "title": "Mesh Path",
      +  "type": "string"
      +}
    • removedInput schema / properties / override_prompt
      Removed value: -{
      -  "title": "Override Prompt",
      -  "type": "string"
      -}
    • addedInput schema / properties / reference_images / description
      Added value: +"A picture the person showed you: an image file path, or a list of them.  Kept on the goal, so every later ``generate`` is checked against it."
    • changedInput schema / properties / scad_code / description
      Previous value: -"Default: \"\"."New value: +"For ``generate``: the OpenSCAD source to compile and check.  Empty asks a configured cloud backend, or hands back the design details for you to write it. Default: \"\"."
    • addedInput schema / properties / spec_numbers / description
      Added value: +"Dimensions settled in conversation, one entry each, with ``label``, ``measurement`` (``bbox_x`` / ``bbox_y`` / ``bbox_z`` / ``volume_mm3`` / ``hole_count`` / ``min_hole_diameter``, or a name Kiln will learn to measure), ``value``, ``origin`` (``\"user_stated\"`` or ``\"kiln_derived\"``) and ``why`` (one plain sentence); ``tolerance`` and ``stated_text`` optional.  Works with every verb; a later entry with the same label replaces the earlier one."
    • addedInput schema / properties / target_size_mm / description
      Added value: +"For ``start``: a size hint in millimetres, kept with the goal; it does not answer the sizing question on its own."
    • addedInput schema / properties / verb / description
      Added value: +"The move to make: ``start``, ``update``, ``save`` (or ``commit``), ``generate`` (or ``make``) and ``join``; any other word is refused."
  2. Addedv1.5.0

TDQS

A3.6/5.0
Behavior4/5

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

Above what the annotations supply: the description explains that Kiln compiles the supplied scad_code into an STL and runs design checks, that the request is persisted as a goal, and that goal_id links later versions and other make tools. It does not address the destructiveHint=true annotation (what a save/update overwrites) or any auth/limits, which leaves one meaningful 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?

Front-loaded with the purpose, then workflow, then verb vocabulary, which is a sensible order. The example list ('a part, a bracket, a box, a holder, a gift') is a small amount of filler, but the rest is tight and every sentence carries information.

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 15-parameter, nested-object, no-output-schema session tool, the description covers the lifecycle and verbs but leaves many parameters' roles (spec_numbers, decided_against, artifact_type, reference_images, join's made_with/mesh_path) to the schema alone. What it does cover is accurate, and the schema's 100% coverage compensates partially.

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 carries per-parameter meaning. The description adds some cross-parameter context — scad_code drives generate, goal_id groups later versions — but does not explain answers, spec_numbers, material_change, reference_images, or mesh_path/join usage beyond naming the verbs.

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?

The definition opens with a concrete verb-plus-resource statement ('Make, design or create any physical object ... as a 3D model ready to print') and names the concrete outputs (STL, OpenSCAD, design checks). It does not, however, distinguish itself from nearby siblings such as generate_model, create_design, or iterate_design, so an agent still has to infer the boundary.

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?

'A specific request goes straight to generate, a vague one gets a quick question or two' gives real internal routing guidance, and the verb list tells the agent which move to make. But there is no statement about when to pick this session tool over the many sibling generation/design tools, and no exclusions.

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