Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

estimate_mesh_weight

Read-only

Estimate the printed weight of STL, OBJ, GLB, 3MF, or STEP models by computing mesh volume and applying material density, infill ratio, and wall thickness for print planning.

Instructions

Estimate the printed weight of a model file (a STEP file is converted first).

        Uses the divergence theorem to compute mesh volume, then applies
        material density, infill ratio, and shell fraction for a realistic
        weight estimate.

        :param file_path: Path to a mesh (.stl, .obj, .glb, .3mf) or a CAD
            file (.step, .stp), which is converted automatically.
        :param material: Material name (pla, abs, petg, tpu, nylon, etc.).
        :param infill_percent: Infill percentage 0-100 (default 20).
        :param wall_thickness_mm: Perimeter wall thickness in mm (default 1.2).
        :returns: Dict with volume, weight estimates, bounding box.

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_weight"
  }
}

Input Schema

NameRequiredDescriptionDefault
materialNoMaterial name (pla, abs, petg, tpu, nylon, etc.). Default: "pla".
file_pathYesPath to a mesh (.stl, .obj, .glb, .3mf) or a CAD file (.step, .stp), which is converted automatically.
infill_percentNoInfill percentage 0-100 (default 20). Default: 20.0.
wall_thickness_mmNoPerimeter wall thickness in mm (default 1.2). Default: 1.2.

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 / infill_percent / description
      Previous value: -"Default: 20.0."New value: +"Infill percentage 0-100 (default 20). Default: 20.0."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"pla\"."New value: +"Material name (pla, abs, petg, tpu, nylon, etc.). Default: \"pla\"."
    • changedInput schema / properties / wall_thickness_mm / description
      Previous value: -"Default: 1.2."New value: +"Perimeter wall thickness in mm (default 1.2). Default: 1.2."
  2. Changed6 schema fields changedv1.5.0
    • removedInput schema / properties / infill_percent / default
      Removed value: -20
    • addedInput schema / properties / infill_percent / description
      Added value: +"Default: 20.0."
    • removedInput schema / properties / material / default
      Removed value: -"pla"
    • addedInput schema / properties / material / description
      Added value: +"Default: \"pla\"."
    • removedInput schema / properties / wall_thickness_mm / default
      Removed value: -1.2
    • addedInput schema / properties / wall_thickness_mm / description
      Added value: +"Default: 1.2."
  3. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds real context beyond them: the divergence-theorem volume computation, the automatic STEP/STP conversion, and the modeled inputs of density, infill, and shell fraction. That tells the agent the result is a model-based approximation rather than a slicer-exact figure, which the annotations alone would not convey.

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 opening sentence is well front-loaded and the method note earns its place, but the four :param lines duplicate the schema descriptions almost verbatim and add length without information. Roughly a third of the text is redundant for an agent that already receives the schema.

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 steps in to name the return contents ('Dict with volume, weight estimates, bounding box'), which is exactly what the agent needs to use the result. Combined with read-only annotations and full param documentation, the definition is complete for a pure computation tool; only the accuracy caveat on the estimate is left implicit.

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% and the description's :param lines largely restate the schema text, so the baseline is 3. It edges slightly higher because 'shell fraction' framing ties wall_thickness_mm to how the weight is derived, and it flags the accepted format families for file_path, but there is no new syntax, range, or default information beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Estimate the printed weight of a model file') and clarifies that STEP inputs are converted first. It is unambiguously about weight rather than time or cost, though it never names near-neighbours like estimate_mesh_print_time or estimate_print_cost_from_mesh to sharpen the boundary.

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

Usage Guidelines3/5

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

Usage is implied by the purpose: call this when you need a filament weight estimate from a mesh or CAD file. There is no explicit when-to-use/when-not statement and no routing to alternatives such as the time or cost estimators in the sibling list, leaving the agent to infer selection.

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