Skip to main content
Glama

estimate_mesh_print_time

Read-only

Estimate rough 3D print time directly from mesh or CAD files before slicing, using layer height and print speed to return planning ranges.

Instructions

Rough print time estimate from mesh geometry (STL/OBJ/GLB; a STEP file is converted first).

        Divides the plastic the part needs by the rate a print head lays
        it down, plus per-layer overhead.  It is a planning figure for a
        printer it is not told about: ``range_seconds`` is how far a real
        slice has sat from it, and the printer is most of that spread.

        Unlike estimate_print_time (which slices the part with the
        printer's profile, and is the real answer when a slicer is
        installed), this works directly on mesh files before slicing.

        :param file_path: Path to a mesh (.stl, .obj, .glb, .3mf) or a CAD
            file (.step, .stp), which is converted automatically.
        :param layer_height_mm: Layer height for slicing.
        :param print_speed_mm_s: Average print speed in mm/s.
        :param material: Material hint (affects per-layer overhead).
        :returns: Dict with estimated time, its range, layer count,
            deposited plastic, assumptions, and note.
        

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

Input Schema

NameRequiredDescriptionDefault
materialNoMaterial hint (affects per-layer overhead). Default: "pla".
file_pathYesPath to a mesh (.stl, .obj, .glb, .3mf) or a CAD file (.step, .stp), which is converted automatically.
layer_height_mmNoLayer height for slicing. Default: 0.2.
print_speed_mm_sNoAverage print speed in mm/s. Default: 60.0.

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 a mesh (.stl, .obj, .glb, .3mf) or a CAD file (.step, .stp), which is converted automatically."
    • changedInput schema / properties / layer_height_mm / description
      Previous value: -"Default: 0.2."New value: +"Layer height for slicing. Default: 0.2."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"pla\"."New value: +"Material hint (affects per-layer overhead). Default: \"pla\"."
    • changedInput schema / properties / print_speed_mm_s / description
      Previous value: -"Default: 60.0."New value: +"Average print speed in mm/s. Default: 60.0."
  2. Changed6 schema fields changedv1.5.0
    • removedInput schema / properties / layer_height_mm / default
      Removed value: -0.2
    • addedInput schema / properties / layer_height_mm / description
      Added value: +"Default: 0.2."
    • removedInput schema / properties / material / default
      Removed value: -"pla"
    • addedInput schema / properties / material / description
      Added value: +"Default: \"pla\"."
    • removedInput schema / properties / print_speed_mm_s / default
      Removed value: -60
    • addedInput schema / properties / print_speed_mm_s / description
      Added value: +"Default: 60.0."
  3. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the readOnlyHint annotations, it discloses the approximation model (deposited plastic divided by head rate plus per-layer overhead), that no printer profile is used, how to interpret range_seconds empirically, and that STEP files are auto-converted. It stops short of describing failure behavior on unsupported or corrupt files, but the accuracy caveats are unusually substantive.

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 prose is front-loaded and readable, but the trailing ':param file_path / layer_height_mm / print_speed_mm_s / material' block duplicates the schema verbatim and the ':returns' line duplicates what the agent can infer from the call. Roughly a third of the text does not earn its place.

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?

For a 4-parameter read-only estimator with no output schema, the description covers inputs, method, accuracy expectations, conversion behavior, and the keys returned (time, range, layer count, plastic, assumptions, note). An agent can call this and interpret the result correctly without further context.

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 100%, so parameters are already documented and the description largely restates them. It adds only marginal meaning, such as noting that material is a 'hint' affecting per-layer overhead and that CAD formats are converted rather than sliced directly.

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?

Opens with a specific verb+resource+input class: 'Rough print time estimate from mesh geometry (STL/OBJ/GLB...)'. It explicitly contrasts itself with the closely named sibling estimate_print_time, so an agent can distinguish the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the routing rule directly: use this 'before slicing' on mesh files; use estimate_print_time when a slicer with the printer's profile is installed, which 'is the real answer'. It names the alternative and the condition that selects it.

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