Skip to main content
Glama

extract_plate_object

Extracts a single object's G-code from a multi-object Bambu .gcode.3mf file to produce a standalone, directly printable .gcode, preserving start/end sequences and removing other objects' toolpaths.

Instructions

Extract a single object's G-code from a multi-object Bambu .gcode.3mf.

When a .gcode.3mf contains multiple objects (e.g. a lid and a body),
this tool extracts ONLY the G-code for the requested object, producing
a standalone .gcode file that can be printed directly.

The machine start-up (homing, levelling, heating) and end (cool-down,
park) sequences are preserved.  Only the per-layer toolpath sections
for other objects are removed.

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

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

Use ``list_plate_objects`` first to see available object names.

:param file_path: Path to the .gcode.3mf file.
:param object_name: Name (or partial name) of the object to extract.
:param output_dir: Directory for the output .gcode file. Defaults to
    the same directory as the input file.
:param plate_number: Which plate to extract from (1-based, default 1).
:returns: Dict with output path, matched object info, and line counts.

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": "extract_plate_object"
  }
}

Input Schema

NameRequiredDescriptionDefault
file_pathYesPath to the .gcode.3mf file.
output_dirNoDirectory for the output .gcode file. Defaults to the same directory as the input file. Default: "".
object_nameYesName (or partial name) of the object to extract.
plate_numberNoWhich plate to extract from (1-based, default 1). Default: 1.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • addedInput schema / properties / file_path / description
      Added value: +"Path to the .gcode.3mf file."
    • addedInput schema / properties / object_name / description
      Added value: +"Name (or partial name) of the object to extract."
    • changedInput schema / properties / output_dir / description
      Previous value: -"Default: \"\"."New value: +"Directory for the output .gcode file. Defaults to the same directory as the input file. Default: \"\"."
    • changedInput schema / properties / plate_number / description
      Previous value: -"Default: 1."New value: +"Which plate to extract from (1-based, default 1). Default: 1."
  2. Changed4 schema fields changedv1.5.0
    • removedInput schema / properties / output_dir / default
      Removed value: -""
    • addedInput schema / properties / output_dir / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / plate_number / default
      Removed value: -1
    • addedInput schema / properties / plate_number / description
      Added value: +"Default: 1."
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false; the description adds the substantive behavior: a new .gcode file is written, machine start/end sequences are preserved, and only other objects' per-layer toolpaths are removed. That tells an agent exactly what the mutation does and what it leaves untouched.

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?

Purpose and the key guarantee are front-loaded, and the paragraphing is easy to scan. The trailing ':param'/':returns' block largely repeats the schema descriptions, which is mild waste given 100% schema coverage, but it does not obscure the main content.

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?

No output schema exists, yet the description specifies the return shape (dict with output path, matched object info, line counts) and the file-system side effect. Combined with the matching rules and preserved-sequence behavior, an agent has everything needed to call this correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by adding matching semantics the schema omits — object matching is case-insensitive and supports partial names ('cap' matches 'TreatHolder - cap.stl'). Plate numbering (1-based, default 1) and output_dir default are restated but not extended.

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?

States a specific verb and resource (extract a single object's G-code from a multi-object Bambu .gcode.3mf) and describes the exact transformation into a standalone .gcode file. It is clearly separable from nearby siblings like list_plate_objects, extract_model_from_3mf, and wrap_gcode_as_3mf.

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?

Gives a concrete precondition: 'Use list_plate_objects first to see available object names,' and explains the multi-object scenario (lid and body) that motivates the tool. It does not explicitly state when NOT to use it or name a competing tool for the single-object case, so it stops short of full alternative routing.

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