Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

mesh_quality_scorecard

Read-only

Generate a graded scorecard for 3D meshes and a CAD intake report that separates exact measurements from mesh-derived data.

Instructions

Assess a model — a graded scorecard for a mesh, an intake report for a CAD file.

        **For a mesh** (.stl, .obj, .glb) it evaluates four dimensions:
        - **Printability** (35%): ``analyze_printability``'s own score and
          grade for ``material`` / ``printer_id`` — pass the ones you gave
          ``analyze_printability`` and the two match
        - **Structural** (25%): aspect ratio, base stability, component count
        - **Efficiency** (20%): fill ratio, support waste
        - **Quality** (20%): triangle density, degenerate count

        and returns per-factor scores, an overall 0-100 score, and a
        letter grade (A-F).  ``subject`` is ``"mesh"``.

        **For a CAD file** (.step, .stp) it returns an INTAKE REPORT and
        deliberately no letter grade.  ``subject`` is ``"cad_file"``,
        ``grade`` is null, and ``grade_withheld`` says why: 20% of that
        score measures Kiln's own tessellation, so the identical part
        would grade differently depending on which converter is installed
        on the machine that read it.  Instead you get three bands:

        - ``exact`` — read from the user's file by the CAD kernel:
          volume, surface area, envelope, validity, solid/shell/face
          counts, in mm.  These match their CAD package to the decimal
          and are the numbers to quote back to them.
        - ``measured`` — what genuinely needs triangles (overhangs,
          stability, floating parts), with the conversion named and this
          part's own conversion difference stated.
        - ``about_our_copy`` — triangle and degenerate counts for Kiln's
          generated mesh, as counts, never scored.

        When quoting a CAD part's size to a user, quote ``exact`` —
        ``about_our_copy`` describes Kiln's mesh, not their design.

        :param file_path: Path to a mesh (.stl, .obj, .glb) or a CAD file
            (.step, .stp).
        :param material: Material the printability factor is judged for
            (default ``"pla"``).
        :param printer_id: Optional printer the printability factor is
            judged for.
        :returns: Dict with scores and a grade for a mesh; the three-band
            intake report with ``grade: null`` for a CAD 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": "mesh_quality_scorecard"
  }
}

Input Schema

NameRequiredDescriptionDefault
materialNoMaterial the printability factor is judged for (default ``"pla"``). Default: "pla".
file_pathYesPath to a mesh (.stl, .obj, .glb) or a CAD file (.step, .stp).
printer_idNoOptional printer the printability factor is judged for. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • addedInput schema / properties / file_path / description
      Added value: +"Path to a mesh (.stl, .obj, .glb) or a CAD file (.step, .stp)."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"pla\"."New value: +"Material the printability factor is judged for (default ``\"pla\"``). Default: \"pla\"."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Optional printer the printability factor is judged for. Default: \"\"."
  2. Changed2 schema fields changedv1.5.0
    • addedInput schema / properties / material
      Added value: +{
+  "description": "Default: \"pla\".",
+  "title": "Material",
+  "type": "string"
+}
    • addedInput schema / properties / printer_id
      Added value: +{
+  "description": "Default: \"\".",
+  "title": "Printer Id",
+  "type": "string"
+}
  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 already declare this is a safe read-only, non-open-world operation, and the description goes well beyond that: it explains why CAD grades are withheld (20% of the score measures Kiln's own tessellation), what each of the three bands means, and that exact values are the numbers to quote back to the user. That is substantive behavioral context an agent could not infer from the annotations.

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 one-line purpose, then structured with bold headers and bullet lists that map cleanly to the two file types. The trailing ':param' block largely restates the schema descriptions and is the main redundancy, keeping it short of a 5.

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?

There is no output schema, so the description carries the return-value burden and does so fully: per-factor scores, overall 0-100 score and A-F grade for meshes; grade null plus grade_withheld and three named bands for CAD. Nothing an agent needs to call or interpret the result is missing.

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, but the description adds real meaning: material and printer_id drive only the printability factor and are coupled to a prior analyze_printability call, and file_path is clarified as branching between mesh and CAD handling. This coupling is not expressible in the flat schema descriptions.

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?

The opening line gives a specific verb and resource ('Assess a model — a graded scorecard for a mesh, an intake report for a CAD file') and then splits the behavior by file type with concrete extensions. It explicitly contrasts itself with the sibling 'analyze_printability' by explaining that the printability factor is that tool's own score, so an agent can distinguish the two without opening schemas.

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?

Clear context for both modes: use it on a mesh (.stl/.obj/.glb) for a graded scorecard, or on a CAD file (.step/.stp) for an intake report, plus the explicit instruction to pass the same material/printer_id given to analyze_printability so the two match. It lacks explicit when-not guidance against other analysis siblings such as analyze_mesh_geometry or analyze_structural_risks.

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