Skip to main content
Glama

print_plate_object

Destructive

Extract and print one object from a multi-object .gcode.3mf file: pulls the object's G-code, uploads it to the printer, and starts the print with a preflight safety check.

Instructions

Extract a single object from a multi-object .gcode.3mf and print it.

This is a compound workflow tool that performs the complete pipeline
in one call:

1. **Extract** the requested object's G-code (``extract_plate_object``)
2. **Upload** the extracted G-code to the printer (``upload_file``)
3. **Preflight + Start** the print (``start_print``, which runs its
   own preflight safety check)

Bambu Studio supports multiple plates (plate_1, plate_2, etc.).
Use ``plate_number`` to select which plate to extract and print from.

Object matching is case-insensitive and supports partial names:
``"cap"`` matches ``"TreatHolder - cap.stl"``.

Use ``list_plate_objects`` first if you want to preview what's
available before committing to a print.

:param file_path: Path to the .gcode.3mf file.
:param object_name: Name (or partial name) of the object to print.
:param use_ams: AMS mode — ``"auto"``, ``"true"``, or ``"false"``.
:param ams_mapping: The tray per extruder by the printer's tray id
    (e.g. ``[0]`` for slot A1, ``[5]`` for B2; see ``ams_status``).
:param bed_leveling: Run bed leveling before print.
:param flow_cali: Run flow calibration before print.
:param vibration_cali: Run vibration calibration before print.
:param bed_type: Bed surface type (Bambu only): ``"auto"``,
    ``"textured_plate"``, ``"hot_plate"`` (smooth PEI), ``"cool_plate"``,
    ``"eng_plate"`` or ``"supertack_plate"``.
:param plate_number: Which plate to extract from (1-based, default 1).
:param printer_name: Which printer to print on.  Omit for the default
    printer.  Both steps are aimed at it, so the object is uploaded to
    and started on the same machine.
:returns: Dict with extraction info and print start status.
:param preview_token: Token from ``issue_preview_token`` proving the
    object was shown to the person before printing.  Required beside their
    go-ahead: a print is shown to its owner before it starts.

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": {
      "file_path": "<file_path>",
      "object_name": "<object_name>"
    },
    "name": "print_plate_object"
  }
}

Input Schema

NameRequiredDescriptionDefault
use_amsNoAMS mode — ``"auto"``, ``"true"``, or ``"false"``. Default: "auto".
bed_typeNoBed surface type (Bambu only): ``"auto"``, ``"textured_plate"``, ``"hot_plate"`` (smooth PEI), ``"cool_plate"``, ``"eng_plate"`` or ``"supertack_plate"``. Default: "auto".
file_pathYesPath to the .gcode.3mf file.
flow_caliNoRun flow calibration before print. Default: true.
ams_mappingNoThe tray per extruder by the printer's tray id (e.g. ``[0]`` for slot A1, ``[5]`` for B2; see ``ams_status``).
object_nameYesName (or partial name) of the object to print.
bed_levelingNoRun bed leveling before print. Default: true.
plate_numberNoWhich plate to extract from (1-based, default 1). Default: 1.
printer_nameNoWhich printer to print on. Omit for the default printer. Both steps are aimed at it, so the object is uploaded to and started on the same machine.
preview_tokenNoToken from ``issue_preview_token`` proving the object was shown to the person before printing. Required beside their go-ahead: a print is shown to its owner before it starts.
vibration_caliNoRun vibration calibration before print. Default: true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv1.5.1
    • addedInput schema / properties / ams_mapping / description
      Added value: +"The tray per extruder by the printer's tray id (e.g. ``[0]`` for slot A1, ``[5]`` for B2; see ``ams_status``)."
    • changedInput schema / properties / bed_leveling / description
      Previous value: -"Default: true."New value: +"Run bed leveling before print. Default: true."
    • changedInput schema / properties / bed_type / description
      Previous value: -"Default: \"auto\"."New value: +"Bed surface type (Bambu only): ``\"auto\"``, ``\"textured_plate\"``, ``\"hot_plate\"`` (smooth PEI), ``\"cool_plate\"``, ``\"eng_plate\"`` or ``\"supertack_plate\"``. Default: \"auto\"."
    • addedInput schema / properties / file_path / description
      Added value: +"Path to the .gcode.3mf file."
    • changedInput schema / properties / flow_cali / description
      Previous value: -"Default: true."New value: +"Run flow calibration before print. Default: true."
    • addedInput schema / properties / object_name / description
      Added value: +"Name (or partial name) of the object to print."
    • changedInput schema / properties / plate_number / description
      Previous value: -"Default: 1."New value: +"Which plate to extract from (1-based, default 1). Default: 1."
    • addedInput schema / properties / preview_token / description
      Added value: +"Token from ``issue_preview_token`` proving the object was shown to the person before printing.  Required beside their go-ahead: a print is shown to its owner before it starts."
    • addedInput schema / properties / printer_name / description
      Added value: +"Which printer to print on.  Omit for the default printer.  Both steps are aimed at it, so the object is uploaded to and started on the same machine."
    • changedInput schema / properties / use_ams / description
      Previous value: -"Default: \"auto\"."New value: +"AMS mode — ``\"auto\"``, ``\"true\"``, or ``\"false\"``. Default: \"auto\"."
    • changedInput schema / properties / vibration_cali / description
      Previous value: -"Default: true."New value: +"Run vibration calibration before print. Default: true."
  2. Changed15 schema fields changedv1.5.0
    • removedInput schema / properties / ams_mapping / default
      Removed value: -null
    • removedInput schema / properties / bed_leveling / default
      Removed value: -true
    • addedInput schema / properties / bed_leveling / description
      Added value: +"Default: true."
    • removedInput schema / properties / bed_type / default
      Removed value: -"auto"
    • addedInput schema / properties / bed_type / description
      Added value: +"Default: \"auto\"."
    • removedInput schema / properties / flow_cali / default
      Removed value: -true
    • addedInput schema / properties / flow_cali / description
      Added value: +"Default: true."
    • removedInput schema / properties / plate_number / default
      Removed value: -1
    • addedInput schema / properties / plate_number / description
      Added value: +"Default: 1."
    • addedInput schema / properties / preview_token
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "title": "Preview Token"
      +}
    • removedInput schema / properties / printer_name / default
      Removed value: -null
    • removedInput schema / properties / use_ams / default
      Removed value: -"auto"
    • addedInput schema / properties / use_ams / description
      Added value: +"Default: \"auto\"."
    • removedInput schema / properties / vibration_cali / default
      Removed value: -true
    • addedInput schema / properties / vibration_cali / description
      Added value: +"Default: true."
  3. Changed1 schema field changedv1.3.1
    • addedInput schema / properties / printer_name
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Printer Name"
      +}
  4. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already flag this as destructive and non-readOnly; the description adds real context beyond them: the preview_token consent gate, the preflight safety check inside start_print, and that both upload and start target the same printer_name. It does not describe failure behavior (unknown object name, upload failure mid-pipeline) or irreversibility of a started print, which for a destructive tool would be worth a sentence.

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 numbered pipeline is front-loaded and scannable, and the plate/object guidance arrives before the parameter block. The trailing :param list largely duplicates the 100%-covered schema and could be trimmed 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 an 11-parameter destructive workflow with no output schema, the description covers the pipeline stages, plate selection, object matching, printer targeting, AMS mapping, and the consent token, and briefly notes the return type. What it omits is error/abort semantics when extraction or preflight fails partway through a multi-step print.

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%, so most parameter text in the description merely restates the schema field descriptions. The one genuine addition is the concrete case-insensitive partial-match example ("cap" matching "TreatHolder - cap.stl"), plus clarifying that printer_name is shared across both pipeline steps; the rest duplicates structured data, so baseline 3 fits.

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 plus the exact input type (single object out of a multi-object .gcode.3mf, then printed). It explicitly decomposes into the three sibling operations it wraps (extract_plate_object, upload_file, start_print), so an agent can immediately tell it apart from calling those tools individually.

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 selection guidance for plate_number and object_name, and directs the agent to list_plate_objects when it wants a preview before committing to a print. It stops short of saying when NOT to use this compound tool (e.g. when only extraction or only upload is wanted, in which case the sibling tools apply), so a small routing gap remains.

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