Skip to main content
Glama

keep_design

Destructive

Save a Kiln-built make to this computer and return the local file path needed for slicing, printing, or export.

Instructions

Keep a make that Kiln's servers built: save its file to this computer.

    A make from one of Kiln's served tools (a coaster, a textured part,
    a decorated model) is built on Kiln's servers and shown on the
    stage.  Looking at it and changing it are free.  Call this when the
    user wants to KEEP it: to slice, print or export it.  It saves the
    full-quality file on this computer and returns its path
    (``mesh_path``), which every local tool takes.

    On the Free plan a keep counts toward that kind of make's monthly
    allowance, and the answer says how many are left (``keep``).  Paid
    plans keep without limit.  A make is only ever counted once.

    Args:
        artifact_token: The token of the make to keep.  It is in the
            make's own answer, under ``made_on_kiln_servers``.
    

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": {
      "artifact_token": "<artifact_token>"
    },
    "name": "keep_design"
  }
}

Input Schema

NameRequiredDescriptionDefault
artifact_tokenYesThe token of the make to keep. It is in the make's own answer, under ``made_on_kiln_servers``.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / artifact_token / description
      Added value: +"The token of the make to keep.  It is in the make's own answer, under ``made_on_kiln_servers``."
  2. Addedv1.5.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description earns credit for explaining why that matters — a keep consumes a Free-plan monthly allowance, paid plans are unlimited, and a make is counted only once. It also discloses the side effect (a full-quality file written locally) and the key return value. It doesn't mention overwrite behavior or failure modes, so it stops short of full transparency.

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 action and file-saving effect, then the when-to-call rule, then billing nuance. The trailing Args block re-states the input schema and the docstring indentation is noisy, but no sentence is genuinely wasted.

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

Completeness5/5

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

With no output schema, the description carries the return-value burden and does so: it names mesh_path and the remaining-keep count, notes that mesh_path is what every local tool takes, and covers quota semantics. That is sufficient for an agent to call this correctly and interpret the result.

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%, and the description's parameter guidance (token is in the make's answer under made_on_kiln_servers) duplicates the schema text verbatim. It adds workflow context on where the token comes from but no new syntax or format detail beyond the schema.

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?

The first sentence states a specific verb and resource ("Keep a make that Kiln's servers built") plus the concrete effect ("save its file to this computer"). It also scopes the concept precisely by contrasting the free operations (looking at / changing) against the paid keep, which separates it from stage-viewing and edit siblings.

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

Usage Guidelines4/5

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

It gives an explicit trigger: "Call this when the user wants to KEEP it: to slice, print or export it," and implicitly excludes view/edit actions as free. It does not name a specific alternative tool (e.g. show_on_stage or download_generated_model) for the non-keep paths, so routing relies on inference.

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