Skip to main content
Glama

smart_reprint

Reprint a 3D model with a different material in one call — finds the file, detects the AMS slot, adjusts slicer settings, and starts printing.

Instructions

Smart one-shot material-switch reprint — finds the model, detects the right AMS slot, adjusts slicer settings, and prints.

This is the highest-level reprinting tool. Give it a file name (or
partial name) and a target material, and it handles everything:

1. **Find the model**: Searches print history for the file name, then
   searches common local directories for the source STL/3MF/STEP file.
2. **Check AMS**: Reads AMS tray status to find which slot has the
   target material loaded. Auto-selects the matching slot.
3. **Build overrides**: Generates material-specific slicer overrides
   (temperature, speed, retraction) for the target material.
4. **Reslice + print**: Reslices the model with new settings and
   starts the print with the correct AMS mapping.

Example: "Reprint my grip extension in PETG"::

    smart_reprint(
        file_name="grip_extension",
        material_id="petg",
        printer_name="my_bambu",
        printer_id="bambu_a1",
    )

The tool will find ``grip_extension.stl`` on disk, detect that PETG
is loaded in AMS slot 1, adjust temps/speeds for PETG, reslice, and
start printing — all in one call.

Saved-goal carry-forward: when the source model on disk has a
``<file>.intent.json`` sidecar tagged with a saved goal, that
goal's id is auto-recovered and surfaced as ``brief_id`` in the
result so downstream ``record_print_outcome`` correctly links the
reprint back to the goal. Pass ``brief_id="..."`` explicitly to
override the sidecar derivation (rare — useful for one-off
re-attributions).

Args:
    file_name: Full or partial file name to search for (e.g.
        ``"grip_extension"`` or ``"grip_extension.stl"``).
        Searched in print history first, then in local directories.
    material_id: Target material (e.g. ``"petg"``, ``"tpu"``).
    printer_name: Registered printer name in fleet.
    printer_id: Printer model ID for profile selection.
    search_dirs: Optional JSON array of extra directories to search
        for the model file (e.g. ``'["/home/user/models"]'``).
    extra_overrides: Optional JSON string of additional slicer
        overrides (e.g. ``'{"fill_density": "30%"}'``).
    auto_ams: If ``True`` (default), automatically detect AMS slot
        for the target material. Set to ``False`` to skip AMS
        detection (useful for non-Bambu printers).
    brief_id: Optional saved-goal id from ``design_session``.  When
        omitted, the source model's intent sidecar (if any) is read
        and the saved goal's id is derived from its ``generator``
        field — so a reprint of a brief-attached design keeps the
        goal link automatically.  Best-effort: missing kiln-pro or
        missing sidecar silently skips.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
auto_amsNo
brief_idNo
file_nameYes
printer_idNo
material_idYes
search_dirsNo
printer_nameNo
extra_overridesNo
Behavior4/5

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

With no annotations provided, the description fully describes the tool's internal logic: searching print history and local directories, auto-detecting AMS slot, generating slicer overrides, and saved-goal carry-forward. It explains best-effort behavior for brief_id derivation, providing good 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?

The description is comprehensively structured with a summary, numbered steps, an example, and parameter details. While slightly verbose, it is front-loaded with the core purpose and well-organized, making it easy to scan.

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?

Given the tool's complexity (8 parameters, no output schema), the description covers the full workflow, parameter semantics, and edge cases like saved-goal carry-forward. It provides sufficient context for an AI agent to understand when and how to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description includes a detailed Args section explaining each parameter's purpose, default behavior, and optional use cases (e.g., 'brief_id' derivation from sidecar, 'auto_ams' for non-Bambu printers). This adds substantial meaning beyond the raw 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 description clearly defines the tool as a 'Smart one-shot material-switch reprint' and lists its four-step process: find model, check AMS, build overrides, reslice+print. It distinguishes itself as the highest-level reprinting tool, differentiating from simpler sibling tools like 'reprint_with_material' or 'run_reslice_and_print'.

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?

The description provides a realistic example and states it handles everything given file name and material. However, it does not explicitly caution when to use a simpler tool or when not to use this one, leaving some ambiguity about trade-offs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/codeofaxel/kiln'

If you have feedback or need assistance with the MCP directory API, please join our Discord server