Skip to main content
Glama

download_model

Downloads marketplace model files to local storage and converts GLBs to STLs for preview, slicing, or printing, with optional file selection and destination control.

Instructions

Download model file(s) from a marketplace to local storage.

        **Community models are unverified.** Always preview dimensions and
        validate the mesh (``validate_generated_mesh``) before printing.
        Models with high download counts and positive ratings are generally
        safer.  AI-generated or untested designs can damage delicate printer
        hardware — prefer proven blueprints when possible.

        Args:
            brief_id: The saved goal's id from ``design_session``, so this make
                is recorded against the goal and checked against it. Empty when
                there is no goal.
            file_id: Numeric file ID (from ``model_files`` results).  If
                omitted and ``model_id`` is provided, downloads all files
                for the model.
            dest_dir: Local directory to save into.  Default: Kiln's own
                downloads folder in the temp directory (the reply names
                the path).
            file_name: Override the saved file name (single-file mode only).
                Defaults to the original name from the marketplace.
            model_id: Model/thing ID.  When ``file_id`` is omitted,
                all files for this model are downloaded.
            source: Marketplace source — ``"thingiverse"`` (default),
                ``"myminifactory"``, etc.
            download_all: When True, downloads all files for the model
                regardless of whether ``file_id`` is provided.

        A downloaded GLB is handed on as an STL beside it, because the
        stage, the slicer and printers cannot open a GLB: its
        ``local_path`` is the STL, and ``conversion`` names the
        original, which stays on disk (``conversion_failed`` says so
        when a GLB cannot be read).  The stage opens on the first
        downloaded file it can draw, and
        the result measures that file (``validation``, ``dimensions``;
        ``size_check`` when its size reads like a units mix-up) and says
        where the files came from (``came_from``: the marketplace and,
        when its listing could be read, the designer, license and page).
        A note beside each file keeps where it came from, so the stage
        and design history can say so later; ``show_on_stage(path)``
        opens any of the other files.  Then upload to a printer with
        ``upload_file`` and print with ``start_print``.

INLINE 3D STAGE: on success this tool opens Kiln's interactive 3D stage — an inline viewer panel the user can orbit, zoom, and turn over — in hosts that render MCP Apps panels (Kiln's hosted connection attaches a browser stage link for hosts that don't). Oversized meshes are decimated automatically for the stage; the PNG preview is the floor, not the whole experience.

MAKE DOORS: design_session, Kiln's front door for making an object, is not installed here (signed in to Kiln it runs on Kiln's servers). On this install compile_scad IS the make → preview → iterate loop: make it, show the preview, iterate.

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_model"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceNoMarketplace source — ``"thingiverse"`` (default), ``"myminifactory"``, etc. Default: "thingiverse".
file_idNoNumeric file ID (from ``model_files`` results). If omitted and ``model_id`` is provided, downloads all files for the model.
brief_idNoThe saved goal's id from ``design_session``, so this make is recorded against the goal and checked against it. Empty when there is no goal. Default: "".
dest_dirNoLocal directory to save into. Default: Kiln's own downloads folder in the temp directory (the reply names the path).
model_idNoModel/thing ID. When ``file_id`` is omitted, all files for this model are downloaded.
file_nameNoOverride the saved file name (single-file mode only). Defaults to the original name from the marketplace.
download_allNoWhen True, downloads all files for the model regardless of whether ``file_id`` is provided. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.5.1
    • changedInput schema / properties / brief_id / description
      Previous value: -"Default: \"\"."New value: +"The saved goal's id from ``design_session``, so this make is recorded against the goal and checked against it. Empty when there is no goal. Default: \"\"."
    • addedInput schema / properties / dest_dir / description
      Added value: +"Local directory to save into.  Default: Kiln's own downloads folder in the temp directory (the reply names the path)."
    • changedInput schema / properties / download_all / description
      Previous value: -"Default: false."New value: +"When True, downloads all files for the model regardless of whether ``file_id`` is provided. Default: false."
    • addedInput schema / properties / file_id / description
      Added value: +"Numeric file ID (from ``model_files`` results).  If omitted and ``model_id`` is provided, downloads all files for the model."
    • addedInput schema / properties / file_name / description
      Added value: +"Override the saved file name (single-file mode only). Defaults to the original name from the marketplace."
    • addedInput schema / properties / model_id / description
      Added value: +"Model/thing ID.  When ``file_id`` is omitted, all files for this model are downloaded."
    • changedInput schema / properties / source / description
      Previous value: -"Default: \"thingiverse\"."New value: +"Marketplace source — ``\"thingiverse\"`` (default), ``\"myminifactory\"``, etc. Default: \"thingiverse\"."
  2. Changed9 schema fields changedv1.5.0
    • addedInput schema / properties / brief_id
      Added value: +{
      +  "description": "Default: \"\".",
      +  "title": "Brief Id",
      +  "type": "string"
      +}
    • removedInput schema / properties / dest_dir / default
      Removed value: -null
    • removedInput schema / properties / download_all / default
      Removed value: -false
    • addedInput schema / properties / download_all / description
      Added value: +"Default: false."
    • removedInput schema / properties / file_id / default
      Removed value: -null
    • removedInput schema / properties / file_name / default
      Removed value: -null
    • removedInput schema / properties / model_id / 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.1/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description goes far beyond that by disclosing the GLB→STL handoff, the conversion_failed flag, that the original stays on disk, the stage auto-opening on the first drawable file, and that the result carries validation, dimensions, size_check and came_from. It also warns about untrusted third-party content and hardware risk, which no annotation conveys.

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 purpose is front-loaded and sectioned with headers, which helps scanning. However, the seven-item Args block is pure duplication of a fully-covered schema, and the appended INLINE 3D STAGE and MAKE DOORS paragraphs are lengthy host/marketing context that dilutes the tool's own definition.

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?

There is no output schema, and the description compensates thoroughly by describing the returned local_path, conversion, validation, dimensions and came_from fields plus the sidecar notes. For a networked, multi-file download with a follow-on pipeline, an agent has everything needed to call it 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 description coverage is already 100%, and the Args block in the description largely restates those same property descriptions rather than adding new meaning. The one genuinely useful addition is the documented precedence between download_all, file_id and model_id, but the rest duplicates structured data, so 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?

The opening sentence gives a specific verb and resource — 'Download model file(s) from a marketplace to local storage' — which immediately separates this from mesh-editing and print-start tools. It never names its closest siblings (download_generated_model, download_and_upload, cache_model), so an agent must infer the boundary itself, which keeps it from a 5.

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?

Usage context is explicit: community models are unverified, preview dimensions and run validate_generated_mesh before printing, and after download continue with upload_file then start_print. The file_id/model_id/download_all interaction is spelled out as a selection rule. What is missing is exclusion guidance against the similar download/cache siblings.

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