Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

download_and_upload

Destructive

Downloads selected model files from Thingiverse or MyMiniFactory and uploads them to a target 3D printer for review before printing.

Instructions

Download model file(s) from any marketplace and upload to a printer.

**Community models are unverified.** This tool downloads and uploads
but does NOT start printing automatically.  You must call
``start_print`` separately after reviewing the uploaded file.
3D printers are delicate hardware — misconfigured or malformed models
can cause physical damage.

When ``file_id`` is provided, downloads and uploads that single file.
When ``model_id`` is provided without ``file_id``, downloads and
uploads all printable files (.stl, .gcode, .3mf, .glb) for the model.
A GLB goes to the printer as an STL beside it, never as a GLB; the
upload's ``conversion`` names the original, which stays on disk.

Args:
    file_id: File ID (from ``model_files`` results).  For Thingiverse
        this is a numeric ID; for MyMiniFactory it's the file ID string.
        If omitted and ``model_id`` is given, all printable files are
        downloaded and uploaded.
    source: Which marketplace to download from — "thingiverse" (default)
        or "myminifactory".  Cults3D does not support direct downloads.
    printer_name: Target printer name.  Omit to use the default printer.
    model_id: Model/thing ID.  When ``file_id`` is omitted, all
        printable files for this model are downloaded and uploaded.

After uploading, review the model and call ``start_print`` to begin.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "download_and_upload"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceNoWhich marketplace to download from — "thingiverse" (default) or "myminifactory". Cults3D does not support direct downloads. Default: "thingiverse".
file_idNoFile ID (from ``model_files`` results). For Thingiverse this is a numeric ID; for MyMiniFactory it's the file ID string. If omitted and ``model_id`` is given, all printable files are downloaded and uploaded.
model_idNoModel/thing ID. When ``file_id`` is omitted, all printable files for this model are downloaded and uploaded.
printer_nameNoTarget printer name. Omit to use the default printer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • addedInput schema / properties / file_id / description
      Added value: +"File ID (from ``model_files`` results).  For Thingiverse this is a numeric ID; for MyMiniFactory it's the file ID string. If omitted and ``model_id`` is given, all printable files are downloaded and uploaded."
    • addedInput schema / properties / model_id / description
      Added value: +"Model/thing ID.  When ``file_id`` is omitted, all printable files for this model are downloaded and uploaded."
    • addedInput schema / properties / printer_name / description
      Added value: +"Target printer name.  Omit to use the default printer."
    • changedInput schema / properties / source / description
      Previous value: -"Default: \"thingiverse\"."New value: +"Which marketplace to download from — \"thingiverse\" (default) or \"myminifactory\".  Cults3D does not support direct downloads. Default: \"thingiverse\"."
  2. Changed5 schema fields changedv1.5.0
    • removedInput schema / properties / file_id / default
      Removed value: -null
    • removedInput schema / properties / model_id / default
      Removed value: -null
    • removedInput schema / properties / printer_name / default
      Removed value: -null
    • removedInput schema / properties / source / default
      Removed value: -"thingiverse"
    • addedInput schema / properties / source / description
      Added value: +"Default: \"thingiverse\"."
  3. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already flag destructiveHint and openWorldHint, but the description adds real context on top: community models are unverified, misconfigured models can physically damage hardware, file conversion behavior (a GLB is sent as an STL and the original stays on disk, named in the upload's conversion field). That is substantive operational and side-effect disclosure that the annotations alone do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical warning and the not-printing constraint are front-loaded, which is good, but the 'call start_print after reviewing' instruction appears twice and the entire Args block duplicates schema text word for word. Roughly a third of the text could be removed without losing information.

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?

For a four-parameter, no-output-schema mutation tool, the definition covers inputs, side effects, conversion behavior, and the required next step well. It stops short of describing failure modes (unsupported model, printer full, download error) or where on the printer the file lands, which would matter for recovery.

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 documents all four parameters, and the description's Args block largely restates it verbatim. The one piece of added meaning — the interdependence between file_id and model_id — is also already present in the schema's own descriptions, so no value is added beyond structured data.

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 line names a specific two-step action (download from a marketplace, upload to a printer) against a named resource. It also explicitly delimits scope by stating the tool does NOT start printing, which separates it from start_print, slice_and_print, and generate_and_print in the sibling list.

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 clear parameter-driven branching: file_id alone means one file, model_id without file_id means all printable files (.stl/.gcode/.3mf/.glb), and source selects Thingiverse vs MyMiniFactory with Cults3D explicitly excluded. It also states the required follow-up call to start_print. What it lacks is routing against sibling tools like download_model + upload_file, which an agent could plausibly choose instead.

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