Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

validate_and_prepare

Validates and prepares any 3D model for printing by checking format, mesh integrity, watertightness, bed fit, and material risks, then returns a pass/fail report with fixes and a printability score.

Instructions

Comprehensive validation pipeline for any 3D model before printing.

        Runs format check, mesh analysis, watertight check, auto-repair,
        printability analysis, structural assessment, bed-fit check, and
        (optionally) material-specific checks.
        Returns a detailed pass/fail report with actionable recommendations
        plus a numeric printability score (0-100).

        Works with any model — AI-generated, downloaded from marketplaces,
        or created in CAD.  Every model passes Kiln's engineering review
        before it touches your printer.

        Each step is resilient — if a step's underlying module is unavailable
        the step is skipped and the pipeline continues.

        :param input_path: Path to a 3D model file (.stl, .3mf, .obj, .step, .glb).
        :param printer_id: Optional printer model ID (e.g. "bambu_a1") for
            bed-fit checking.  If empty, bed-fit check is skipped.
        :param material: Optional material name (e.g. "pla", "petg", "abs",
            "asa", "tpu").  When provided, adds a material-specific check
            for known print-quality risks.  If empty, material check is skipped.
        :returns: Dict with pass/fail status, per-check details, recommendations,
            ``printability_score`` and ``printability_grade``
            (analyze_printability's, for ``material`` and ``printer_id``;
            ``None`` when the analysis could not run), and
            ``readiness_score`` (0-100, the tally of the checks) with its
            ``score_breakdown``.

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": {
      "input_path": "<input_path>"
    },
    "name": "validate_and_prepare"
  }
}

Input Schema

NameRequiredDescriptionDefault
materialNoOptional material name (e.g. "pla", "petg", "abs", "asa", "tpu"). When provided, adds a material-specific check for known print-quality risks. If empty, material check is skipped. Default: "".
input_pathYesPath to a 3D model file (.stl, .3mf, .obj, .step, .glb).
printer_idNoOptional printer model ID (e.g. "bambu_a1") for bed-fit checking. If empty, bed-fit check is skipped. Default: "".

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • addedInput schema / properties / input_path / description
      Added value: +"Path to a 3D model file (.stl, .3mf, .obj, .step, .glb)."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"\"."New value: +"Optional material name (e.g. \"pla\", \"petg\", \"abs\", \"asa\", \"tpu\").  When provided, adds a material-specific check for known print-quality risks.  If empty, material check is skipped. Default: \"\"."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Optional printer model ID (e.g. \"bambu_a1\") for bed-fit checking.  If empty, bed-fit check is skipped. Default: \"\"."
  2. Changed4 schema fields changedv1.5.0
    • removedInput schema / properties / material / default
      Removed value: -""
    • addedInput schema / properties / material / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / printer_id / default
      Removed value: -""
    • addedInput schema / properties / printer_id / description
      Added value: +"Default: \"\"."
  3. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Beyond the annotations there is real behavioral content: each step is resilient and skipped when its module is unavailable, and the return payload includes pass/fail status, per-check details, recommendations, printability_score/grade, and readiness_score. Two gaps remain: 'auto-repair' implies file mutation but the description never says whether the original file is rewritten or a new artifact is produced, and there is no note on runtime cost or whether input_path is local vs remote.

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 step enumeration is front-loaded and useful, but the description is bloated by a duplicated ':param'/':returns' block that mirrors the schema and an output schema that already exists, plus a marketing sentence ('Every model passes Kiln's engineering review...') that earns no place.

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 a 3-parameter tool with an output schema and annotations, coverage is strong: parameters, return composition, and degraded-mode behavior are all addressed. The remaining omission is mutation semantics — an agent cannot tell whether the pipeline modifies or writes files, which matters given readOnlyHint=false on a tool that performs auto-repair.

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 the baseline is 3. The ':param' block largely restates the schema text; the only added nuance is the implicit coupling that leaving printer_id/material empty skips the corresponding checks, which is already stated in the schema property descriptions.

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?

The first line states a specific verb and resource ('validation pipeline for any 3D model') and the enumerated steps (format check, mesh analysis, watertight check, auto-repair, printability, bed-fit, material check) make the tool's scope concrete. It does not, however, distinguish itself from the many near-identical siblings such as analyze_printability, validate_and_prepare_mesh, repair_mesh, check_print_readiness, and preflight_check.

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?

Timing is implied ('before printing', 'before it touches your printer'), so an agent can infer the use case. But with roughly a dozen sibling tools covering overlapping pre-print validation, repair, and readiness checks, the description offers no explicit 'use this instead of X when Y' guidance or exclusions.

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