Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

extract_file_metadata

Read-only

Parse 3D print files (.gcode, .3mf, .stl, .ufp) to read estimated print time, layer count, filament usage, dimensions, and slicer/material info without re-slicing.

Instructions

Extract metadata from a 3D printing file (.gcode, .3mf, .stl, .ufp).

Parses file headers for estimated print time, layer count, filament usage,
dimensions, slicer info, and material hints — without re-slicing.  A
project saved from Bambu Studio, OrcaSlicer or PrusaSlicer also gives the
printer, nozzle size, layer height and material it was set up for; hand
the same file to ``set_printer_model`` to set a saved printer up from it.

.. note::
    For multi-object .gcode.3mf files, also consider using
    ``list_plate_objects()`` to see individual objects on the plate.

Args:
    file_path: Path to the print file.

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>"
    },
    "name": "extract_file_metadata"
  }
}

Input Schema

NameRequiredDescriptionDefault
file_pathYesPath to the print file.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / file_path / description
      Added value: +"Path to the print file."
  2. 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 declare readOnlyHint=true, so the safety profile is covered; the description still adds meaningful behavior — it parses headers rather than re-slicing, which tells the agent this is fast and non-mutating, and that richer output depends on whether the file is a Bambu/Orca/Prusa project file. It does not state how unparseable or unsupported files behave.

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?

Front-loaded with the verb, resource and supported formats, then what is extracted, then cross-references. The Args block duplicates the schema and the note adds length, but every sentence carries useful 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?

With no output schema, the description correctly compensates by enumerating the returned fields (print time, layer count, filament usage, dimensions, slicer info, material hints) and the extra fields for project files. Failure modes for corrupt or scanned-only .stl files are the only notable omission.

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?

There is a single required parameter at 100% schema coverage, and the description just repeats 'file_path: Path to the print file'. The format list in the body indirectly constrains acceptable inputs, but no additional syntax, relative-path, or size semantics are added beyond the 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?

States a specific verb and resource (extract metadata from a 3D printing file), enumerates the supported extensions (.gcode, .3mf, .stl, .ufp), and names the exact fields returned, so it is immediately distinguishable from siblings like analyze_print_file or extract_plate_object.

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 concrete routing: hand the same file to set_printer_model to configure a saved printer, and consider list_plate_objects for multi-object .gcode.3mf files. It lacks an explicit 'when not to use' or a contrast with the closely named analyze_print_file sibling.

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